> 1747959390 74588 PRIVMSG #esolangs :14[[07Quite BASIC14]]4 10 02https://esolangs.org/w/index.php?diff=158304&oldid=158205 5* 03Tommyaweosme 5* (+9311) 10
> 1747959659 920171 PRIVMSG #esolangs :14[[07Markov algorithm14]]4 10 02https://esolangs.org/w/index.php?diff=158305&oldid=156494 5* 03Tommyaweosme 5* (+437) 10added explanation of mass
< 1747960430 934189 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Remote host closed the connection
> 1747961168 242656 PRIVMSG #esolangs :14[[07Negative Acknowledgement14]]4 N10 02https://esolangs.org/w/index.php?oldid=158306 5* 03Tommyaweosme 5* (+1477) 10Created page with "{{wrongtitle|title=}}  is a language designed to be uninterpretable. If any interpreter is found, it will change its own Esolangs.org page within a ~231 years, unless a specific computer in an underground bunker in the Pacific ocean running Windows
< 1747961683 304953 :chloetax!~chloe@user/chloetax QUIT :Remote host closed the connection
> 1747968633 573210 PRIVMSG #esolangs :14[[07Talk:Negative Acknowledgement14]]4 N10 02https://esolangs.org/w/index.php?oldid=158307 5* 03Aadenboy 5* (+306) 10Created page with "what about compilation? ~~~~"
> 1747975287 630862 PRIVMSG #esolangs :14[[07Talk:Negative Acknowledgement14]]4 10 02https://esolangs.org/w/index.php?diff=158308&oldid=158307 5* 03Cycwin 5* (+48) 10
< 1747976192 42189 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 265 seconds
< 1747976219 73037 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord
> 1747977000 711293 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5*  10deleted "[[02Category:Cannot easily used10]]": unapproved/undiscussed category; this can probably be handled by see-alsos for the time being, and even if it turns out to be a good idea, the name is wrong
> 1747977000 730532 PRIVMSG #esolangs :14[[07Special:Log/delete14]]4 delete10 02 5* 03Ais523 5*  10deleted "[[02Category talk:Cannot easily used10]]": Deleted together with the associated page with reason: unapproved/undiscussed category; this can probably be handled by see-alsos for the time being, and even if it turns out to be a good idea, the name is wrong
> 1747977099 635746 PRIVMSG #esolangs :14[[07Talk:Boltzmann brainfuck14]]4 N10 02https://esolangs.org/w/index.php?oldid=158309 5* 03Ais523 5* (+225) 10a duplicate?
< 1747977548 423263 :chloetax!~chloe@user/chloetax JOIN #esolangs chloetax :chloe
< 1747977572 712958 :chloetax!~chloe@user/chloetax QUIT :Remote host closed the connection
< 1747977597 876557 :chloetax!~chloe@user/chloetax JOIN #esolangs chloetax :chloe
< 1747978882 732058 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Does any browser display a visual representation of the hash of the server certificate?
< 1747979072 404512 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I had mentioned before, the cardinal arithmetic of categories, and I think someone mentioned ordinal arithmetic. Can ordinal arithmetic of categories be defined? I don't know.
< 1747980530 644386 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer
< 1747980980 479442 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 JOIN #esolangs * :Textual User
< 1747985209 98999 :APic!apic@apic.name PRIVMSG #esolangs :Hi
< 1747987473 816821 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: ooh, with some optimized deterministic from seed image generators, with the user's choice between different styles such as anime girls, luxury cars, natural landscape Iceland, natural landscape South America, etc
> 1747987751 332400 PRIVMSG #esolangs :14[[07Rinuk14]]4 10 02https://esolangs.org/w/index.php?diff=158310&oldid=156918 5* 03JIT 5* (+24) 10
> 1747998864 881548 PRIVMSG #esolangs :14[[07User talk:Aadenboy/Self-equaling squares14]]4 10 02https://esolangs.org/w/index.php?diff=158311&oldid=157532 5* 03PkmnQ 5* (+1528) 10Half a proof
> 1747999240 430237 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Elphan 5*  10New user account
> 1747999718 404963 PRIVMSG #esolangs :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=158312&oldid=158206 5* 03Elphan 5* (+129) 10/* Introductions */
> 1748000031 736818 PRIVMSG #esolangs :14[[07Ampell14]]4 N10 02https://esolangs.org/w/index.php?oldid=158313 5* 03Elphan 5* (+2370) 10Created page with "== Description ==  Ampell is a small programming language that uses a stack to do calculations and run commands. It tries to keep things simple by using only a few symbols for different actions. You can push values on a stack, do math, check conditions, and use variables 
> 1748000124 195608 PRIVMSG #esolangs :14[[07BrainWrite14]]4 M10 02https://esolangs.org/w/index.php?diff=158314&oldid=156873 5* 03JIT 5* (+2) 10/* Input Program */
> 1748000252 590507 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158315&oldid=158313 5* 03Elphan 5* (-370) 10/* Syntax */
< 1748000259 436312 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net JOIN #esolangs amby :realname
> 1748000509 439722 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Upcarry1 5*  10New user account
> 1748000756 391674 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158316&oldid=158315 5* 03Elphan 5* (-237) 10
< 1748002937 201388 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1748002979 409494 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a problem that came up in some code that I was writing and I'm still thinking about it: is there a list implementation that supports efficient clone, uncons and append (i.e. concatenation of two lists)?
< 1748002990 651924 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I can easily do two out of three, but all three at once is proving difficult
< 1748003019 560677 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :("efficient clone" is most obviously implemented by making the lists immutable and refcounted, but that makes the other two properties hard to satisfy)
< 1748003032 207942 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1748003048 797568 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't need any other operations other than writing list literals and iterating over the lists (which can be done by cloning them and then calling uncons repeatedly)
< 1748003112 496293 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: don't some of the balanced trees do that? red-black trees or AVL trees if you want log time, or finger trees if you want amortized constant time
< 1748003143 709482 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :s/red-black trees or AVL trees/red-black trees or 2-3 trees or AVL trees/
< 1748003150 455678 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :including clone? I haven't heard of finger trees, I'll check then
< 1748003168 275024 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :you were trying to write a library for the 2-3 trees, weren't you?
< 1748003174 325958 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :finger trees look really promising, actually
< 1748003179 943891 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :wib_jonas: yes, a long time ago
< 1748003182 123903 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I didn't ever finish it
< 1748003243 628582 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: in all these cases, you make all the nodes immutable, as described in Chris Okasaki's book, you copy nodes instead of editing their links in place when you modify the trees, and this means to clone you can just copy a reference to the root node or similar
< 1748003339 996364 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right – it was hard to prevent the memory usage going quadratic with the things I was trying
< 1748003349 175328 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :finger trees are a variant of 2-3 trees that's more difficult to implement, but in exchange inserting or removing an element from either end can be done in amortized constant time instead of just logarithmic time. the Haskell standard library has a type Seq which implements this, giving a list with the properties that you're asking for, at least if
< 1748003349 675440 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I understand what you need correctly
< 1748003356 536192 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and O(log n) probably isn't a disaster but I've become exceptionally perfectionist recently
> 1748003365 44697 PRIVMSG #esolangs :14[[07User talk:Tommyaweosme14]]4 M10 02https://esolangs.org/w/index.php?diff=158317&oldid=158212 5* 03None1 5* (-916) 10The rotated comment covers content
< 1748003470 945763 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :this is something of a weird case because most of the time, these lists are going to be quite small but could theoretically be large, so a theoretically perfect solution would probably start with a naive quadratic algorithm and switch to something more asymptotically efficient (but with worse constant factors) if the lists got larger
> 1748003553 862628 PRIVMSG #esolangs :14[[07User talk:PrySigneToFry14]]4 10 02https://esolangs.org/w/index.php?diff=158318&oldid=158091 5* 03None1 5* (+428) 10/* Any interests on joining our Esolang Tencent QQ group? */
< 1748003572 64866 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but just knowing it's possible helps a lot because I don't have to worry about making sure the algorithm is possible to make efficient any more, I can write the algorithm and optimise it later
< 1748003609 329555 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :ais523: if they're usually small then you can store multiple logical nodes together in a memory node, like the lower few levels of a B-tree.
< 1748003639 507866 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :they're usually small but I have lots of clones with only minor differences
< 1748003657 183096 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which makes condensing them into arrays hard
< 1748003659 695420 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :yeah, then you may have to benchmark what the right node size is
< 1748003704 747259 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, abcd and abce and abcde might all coexist, and ideally the "abc" part of that would be shared to stop memory use going quadratic
< 1748003751 648501 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the algorithm I use this for is basically operating on stacks, and it usually pushes and pops onto one end of them, but a) it needs a history of all the previous stack states and b) occasionally one stack gets concatenated to another
< 1748003934 543712 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :since we're here I also have a data structure question. I want a key-value dictionary (rather than a sequence that keeps its order). I want it as a database on disk in which I can look up and update quickly. so far I could use a balanced tree or hash. but I'd also like a guarantee that if someone examines the data on disk they can derive no
< 1748003935 43460 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :information about the order in which the keys were inserted or anything else about the history (the "no information" can be in the cryptographic sense where it's like 2**-128 bits of information). I know how I can do this with a treap, and I heard legends that there are hash tables (called "commutative) that can do this too though I don't know how.
< 1748003935 543800 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :But here I'm more interested if there's any existing software implementation that can do this and that I can use, especially one that doesn't require an expensive license.
< 1748004021 140419 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :... . you want this to implement an esoteric programming language that has something more general and crazier than unlambda's call-cc?
< 1748004078 386628 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :actually no (I do have plans for such a language but this isn't part of it)
< 1748004161 409776 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm trying to work on an algorithm to convert NPDAs into DPDAs, which is impossible in general but possible in most practically useful cases
> 1748004271 905797 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158319&oldid=158316 5* 03Elphan 5* (+183) 10
> 1748004315 299867 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158320&oldid=158319 5* 03Elphan 5* (+121) 10
> 1748004329 114379 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158321&oldid=158320 5* 03Elphan 5* (+1) 10/* Prints "hi" how many times you want= */
< 1748004338 631781 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and it works by trying to simulate all the possible states of the NPDA stack in parallel, and checking to see whether there's been a combinatorial explosion or not – so I have a lot of very similar stacks that all need to be stored at once
> 1748004487 391104 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158322&oldid=158321 5* 03Elphan 5* (+228) 10/* Description */
< 1748004492 847574 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :oh, that might be interesting. we were talking some weeks ago about how to implement mutex locking in multi-threaded brainfuck. so I later had an idea, but I can't tell if it's right, so I was thinking that I should implement a verifying program that generates all the possible states of the system (two processors plus shared memory cells) and does
< 1748004493 347729 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :graph traversals on them to prove the properties that I want. the problem is, even if I write the program I wouldn't be confident that I'm checking the right thing, but it still helps. now this sort of locking would be much easier if you could just use nondeterminism (I think that may be kind of how transactional memory works), and if you could
< 1748004493 847575 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :eliminate the nondeterminism automatically then maybe you could automatically generate correct locking algorithms in an ordinary deterministic model.
< 1748004666 243498 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1748004755 611647 PRIVMSG #esolangs :14[[07User talk:Ais52314]]4 10 02https://esolangs.org/w/index.php?diff=158323&oldid=158163 5* 03None1 5* (+346) 10/* Can you prove computatioal class for esolang xVector? */ new section
< 1748004993 264387 :impomatic!~impomatic@2a00:23c7:5fc9:5401:71af:7c8b:cf7b:1b45 JOIN #esolangs * :[https://web.libera.chat] impomatic
> 1748005051 637690 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158324&oldid=158322 5* 03Elphan 5* (+24) 10
> 1748005473 429194 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158325&oldid=158324 5* 03Elphan 5* (+4) 10
> 1748005582 970505 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158326&oldid=158325 5* 03Elphan 5* (-4) 10
> 1748005684 365211 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=158327&oldid=158299 5* 03Elphan 5* (+13) 10/* A */
> 1748005713 783383 PRIVMSG #esolangs :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=158328&oldid=158327 5* 03Elphan 5* (+0) 10/* A */
> 1748005858 377412 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158329&oldid=158326 5* 03Elphan 5* (+43) 10
> 1748005982 935435 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158330&oldid=158329 5* 03Elphan 5* (+10) 10
> 1748007357 595508 PRIVMSG #esolangs :14[[07XVector14]]4 10 02https://esolangs.org/w/index.php?diff=158331&oldid=157941 5* 03Ais523 5* (+3378) 10computational class (it's equivalent to a 1-counter machine, which doesn't have a category)
> 1748007434 329505 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158332&oldid=158330 5* 03Elphan 5* (+34) 10/* Prints "hi" how many times you want */
> 1748007442 523287 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158333&oldid=158332 5* 03Elphan 5* (+1) 10
> 1748007694 290561 PRIVMSG #esolangs :14[[07User talk:Ais52314]]4 10 02https://esolangs.org/w/index.php?diff=158334&oldid=158323 5* 03Ais523 5* (+981) 10/* Can you prove computatioal class for esolang xVector? */ it's a one-counter machine
> 1748007848 233500 PRIVMSG #esolangs :14[[07User talk:Ais52314]]4 M10 02https://esolangs.org/w/index.php?diff=158335&oldid=158334 5* 03Ais523 5* (+1) 10/* Can you prove computatioal class for esolang xVector? */ add missing closing parenthesis
< 1748007927 392378 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 JOIN #esolangs * :Textual User
> 1748008445 128956 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158336&oldid=158333 5* 03Elphan 5* (-76) 10
> 1748008547 96608 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158337&oldid=158336 5* 03Elphan 5* (-173) 10/* Description */
> 1748008670 505463 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158338&oldid=158337 5* 03Elphan 5* (-52) 10/* Syntax */
< 1748009696 724777 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
< 1748010405 3533 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname
< 1748011042 976151 :impomatic!~impomatic@2a00:23c7:5fc9:5401:71af:7c8b:cf7b:1b45 QUIT :Quit: Client closed
> 1748011677 585573 PRIVMSG #esolangs :14[[07Ampell14]]4 10 02https://esolangs.org/w/index.php?diff=158339&oldid=158338 5* 03Elphan 5* (-218) 10/* Description */
< 1748011913 219974 :impomatic!~impomatic@2a00:23c7:5fc9:5401:71af:7c8b:cf7b:1b45 JOIN #esolangs * :[https://web.libera.chat] impomatic
> 1748012584 486115 PRIVMSG #esolangs :14[[07FLOORPLAN14]]4 N10 02https://esolangs.org/w/index.php?oldid=158340 5* 03B jonas 5* (+628) 10Created page with "'''FLOORPLAN''' is an esoteric programming language.  == External link ==  * Peter Hebden, Anna Williams, Sofia Wolf, `FLOORPLAN`: The language of the future. [https://sigbovik.org/2025/proceedings.pdf (2024-04-04) ed. the Association for Computational Heresy, *a recor
> 1748012617 154906 PRIVMSG #esolangs :14[[07FLOORPLAN14]]4 10 02https://esolangs.org/w/index.php?diff=158341&oldid=158340 5* 03B jonas 5* (+11) 10
< 1748013031 204791 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 244 seconds
< 1748013201 3173 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
> 1748014094 766548 PRIVMSG #esolangs :14[[07FLOORPLAN14]]4 10 02https://esolangs.org/w/index.php?diff=158342&oldid=158341 5* 03B jonas 5* (+139) 10
< 1748014620 207566 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas
< 1748014778 540615 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :SIGBOVIK 2025 p. 293 says that the name of their system is the character \u200D, but it also says that it's "named after the symbol used for function application", and I think the symbol they mean there is \u2061. Why would they give the former name if it's named after the latter? Weird.
< 1748014899 943558 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :Fortunately it's esoteric but not a language so I probably don't need to create a page for it on the esowiki and so don't have to decide what its name is.
< 1748014944 248486 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed
> 1748015752 998328 PRIVMSG #esolangs :14[[07User programmed14]]4 10 02https://esolangs.org/w/index.php?diff=158343&oldid=158303 5* 03Hotcrystal0 5* (+75) 10
> 1748015984 471549 PRIVMSG #esolangs :14[[07User programmed14]]4 10 02https://esolangs.org/w/index.php?diff=158344&oldid=158343 5* 03Hotcrystal0 5* (+192) 10
> 1748015995 658450 PRIVMSG #esolangs :14[[07User programmed14]]4 10 02https://esolangs.org/w/index.php?diff=158345&oldid=158344 5* 03Hotcrystal0 5* (+6) 10
< 1748016073 927101 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 JOIN #esolangs * :Textual User
> 1748016088 386120 PRIVMSG #esolangs :14[[07User programmed14]]4 10 02https://esolangs.org/w/index.php?diff=158346&oldid=158345 5* 03Hotcrystal0 5* (-2) 10
> 1748016218 108086 PRIVMSG #esolangs :14[[07User programmed14]]4 10 02https://esolangs.org/w/index.php?diff=158347&oldid=158346 5* 03Hotcrystal0 5* (+24) 10adding a category
> 1748016408 542118 PRIVMSG #esolangs :14[[07Black14]]4 10 02https://esolangs.org/w/index.php?diff=158348&oldid=127271 5* 03Hotcrystal0 5* (+31) 10They say this is a cellular automaton disguised as an esolang
> 1748017029 484475 PRIVMSG #esolangs :14[[07Talk:14]]4 10 02https://esolangs.org/w/index.php?diff=158349&oldid=155776 5* 03Hotcrystal0 5* (+276) 10
< 1748017815 377607 :FreeFull!~freefull@79.186.59.252.ipv4.supernova.orange.pl JOIN #esolangs FreeFull :FreeFull
< 1748019666 204739 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name)
< 1748019765 435976 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1748020185 130618 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`unicode 206D
< 1748020187 554101 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​
< 1748020195 864900 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I don't know what I expected
< 1748020223 792975 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :apparently it is ACTIVATE ARABIC FORM SHAPING
< 1748020246 618077 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and 200D is ZERO WIDTH JOINER, which is also useful for Arabic I think
< 1748020247 13072 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`` unidecode $(printf '\u206D')
< 1748020249 624580 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​[U+206D ACTIVATE ARABIC FORM SHAPING]
< 1748020278 686282 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`` unidecode $(printf '\u2061')
< 1748020279 969109 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​[U+2061 FUNCTION APPLICATION]
< 1748020284 725293 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`` unidecode $(printf '\u200D')
< 1748020287 33551 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​[U+200D ZERO WIDTH JOINER]
< 1748020398 281841 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, we have invisible function application, invisible plus, invisible times, invisible comma
< 1748020412 500858 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but no invisible function *composition*
< 1748020457 135003 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :now I'm wondering if it's even possible to write gf(x) to mean g(f(x)) – I think I've seen that notation somewhere but I can't remember where
< 1748020467 490907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but of course invisible composition happens all the time in concatenative langauges
< 1748020644 918959 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I've been pondering how to implement finger trees in Rust – the type system gymnastics used to make them work are beyond even Haskell unless you turn on some extensions, so the whole "make invalid states unrepresentable" thing could be quite difficult
< 1748020705 715118 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I suspect the most efficient solution uses weak typing (i.e. non-disjoint unions), with functions given arguments to tell them what type they're supposed to be acting on and they interpret memory as that type
< 1748020721 688347 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: soryr, I meant \u2061 and \u200D
< 1748020732 319661 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wait, where does 206D come from?
< 1748020760 274864 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :me mixing up the two characters I think
< 1748020771 587803 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I either misread your comment, or miscopied the codepoints into IRC
< 1748020820 404607 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: the one I'm missing is two different characters for invisible function composition depending on whether the function is on the left or right of its argument, but you can argue that the function can be on the right only if it's linear and then it's just an invisible multiplication
< 1748020846 724878 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which meaning of "linear" is this?
< 1748020853 897565 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: there's always LTR and RTL ;-)
< 1748020877 577840 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(Just a reminder that Unicode is a horrific mess.)
< 1748020888 129786 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh right! so I discovered that Arabic numerals were originally the correct way round (i.e. little-endian) – the least significant digit was on the right, but Arabic is a right-to-left language
< 1748020907 632729 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :however, when they started being used in left-to-right languages, the order of the digits wasn't reversed to compensate for the different writing direction
< 1748020917 674725 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that's how we ended up with our numbers the wrong way round
< 1748020935 819821 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: the one where the function is a monoid homomorphism from a monoid to another monoid (usually a group) with the monoid operation is written as multiplication (rather than addition)
< 1748020962 760719 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: well there's also the roman numerals which put the higher-valued ones first
< 1748020984 590118 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"first" - to the left
< 1748020986 258340 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :a special case could be a linear function mapping a (horizontal) vector to another (horizontal) vector in two vector spaces
< 1748020996 517932 :int-e!~noone@int-e.eu PRIVMSG #esolangs :And what about the Babylonians? I don't even know.
< 1748021009 385145 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: is this the same notation which writes the operation that produces a function type from a return type and argument type as exponentiation?
< 1748021085 391344 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 JOIN #esolangs * :Textual User
< 1748021097 227740 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :a few years of codegolf convinced me that little-endianness is correct, about the only time big-endian notations saved bytes was when solving challenges that were based on the way humans write numbers
< 1748021146 6161 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so now I have some likely-unknown person in medieval times to be annoyed at for messing up today's computer science
< 1748021165 998830 :int-e!~noone@int-e.eu PRIVMSG #esolangs :big endian is nice for parsing numbers; little endian is nice for printing numbers
< 1748021172 653846 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: re digit order, I don't know for sure but I suspect that's because al-Khwarizmi, who popularized decimal positional number system to use for arithmetic, didn't write the numbers inline in text, but as tables in displayed figures, so they didn't look like they're supposed to be words in rtl or ltr text
< 1748021177 840460 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and for arithmetic without base conversion
< 1748021222 83512 :int-e!~noone@int-e.eu PRIVMSG #esolangs :> foldl (\x y -> x*10 + y) 0 [1,2,3]
< 1748021223 342078 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esolangs : 123
< 1748021252 911444 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, parsing is slightly more elegant big-endian
< 1748021331 753989 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh wow, those FLOORPLAN authors are at the university I worked at for years
< 1748021357 865813 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: no, there are three different orders: function on the left is what everyone but algebraists write (though algebraists can also write it), function on the right (algebraists use it when the function is linear), and function in the right superscript (when the function need not be linear)
< 1748021372 847945 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :also my description about what linear means above is specifically incorrect
< 1748021383 280102 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :let me try again
< 1748021523 274708 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, I wonder if there is a name for matrices where every row and column contains one 1 (multiplicative identity) and the other elements are 0 (additive identity)? those would be linear in two senses at once
< 1748021653 534762 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so a linear unary function from a vector space to another vector space is a function f such that for any scalars α,β and vectors x,y, f(αx+βy) = αf(x)+βf(y). when a function is like that, an algebraist could write the function call f(x) as fx if they think of x as column vectors, or as xf if they think of x as a row vector. (row and column could be swapped depending on conventions, linear algebra 
< 1748021659 768819 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :has like five boolean dimensions of arbitrary notation conventions). if both vector spaces are finite dimensional then f can be imagined as a matrix and the function call is a matrix multiplication. 
< 1748021850 441607 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :algebraists can be more relaxed with this and generalize to other situations than just a linear function from a vector space to another.
< 1748021895 940829 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, to me there seems to be a rule that if the function goes to the right of the argument, its name has to be a capital letter
< 1748022230 101871 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :now a group homomorphism is a mapping f from a multiplicative group to another such that f(x)f(y)=f(xy). an algebraist can write such a function as a right superscript (exponent), as in instead of f(x) they write x↑f. the origin of this is that if you consider a conjugation with a group element c, defined as f(x)=c⁻¹xc then they write this as a superscript f(x) = x↑c. any conjugation is also a 
< 1748022236 102131 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :group homomorphism because (x↑c)(y↑c) = (c⁻¹xc)(c⁻¹yc) = c⁻¹xyc = (xy)↑c, and that's the same identity that exponentiation to a fixed integer power holds, and exponentiation was already written as a right supersript.
< 1748022314 550946 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and if there's a function that's none of these then an algebraist tries to pick whichever of f(x), fx, xf, x↑f makes the most sense, or might even use other less common notations
< 1748022389 434618 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :like there's right superscript or right subscript for indexing a tensor or any sequence in general
< 1748022407 480966 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and notation can get wilder when a function has multiple arguments
< 1748022734 824315 :impomatic!~impomatic@2a00:23c7:5fc9:5401:71af:7c8b:cf7b:1b45 QUIT :Quit: Client closed
< 1748022948 86702 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, there are quite a few practical advantages to writing the argument first when doing a function call
< 1748022964 881517 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and lots of languges do object.method().method().method() partly because of that
> 1748023047 604261 PRIVMSG #esolangs :14[[07User talk:Tommyaweosme14]]4 M10 02https://esolangs.org/w/index.php?diff=158350&oldid=158317 5* 03Aadenboy 5* (+776) 10adding back the messages but removing the rotation transform
< 1748023066 545855 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :is |> a builtin in Ocaml? I think it is but am not totally sure
< 1748023103 577505 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it's like $ in Haskell but the argument comes before the function, and the associativity makes it chain properly, just like $ does)
< 1748023594 190418 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Many programming languages already have RPN that you have to write the arguments before the function calls, although that is usually using the stack, which is not quite the same as a argument list.
< 1748023628 749504 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I also believe that Unicode is a mess, but you can do something about it e.g. make a program that does not expect you to use Unicode.
< 1748023738 220010 :impomatic!~impomatic@2a00:23c7:5fc9:5401:71af:7c8b:cf7b:1b45 JOIN #esolangs * :[https://web.libera.chat] impomatic
< 1748023982 445072 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :And, roman numbers have a negative position as well.
< 1748024004 326087 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so anyway, literate programming has this thing where the same source code is both interpreted as a traditional programming language source code and printed documentation, but there are a few special transformations during the transformation, like some word are automatically written in bold or italic, and some two-character punctuation is formatted as a specific character. Eg. in C >= means greater 
< 1748024010 334263 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :equal, and in literate C it is formatted as ≥ ; and in Haskell ++ means list concatenation, and it's formatted as two plus signs overlapping horizontally with their vertical lines close to each other and the horizontal line incident. 
> 1748024392 555805 PRIVMSG #esolangs :14[[07User:RobinsAviary14]]4 N10 02https://esolangs.org/w/index.php?oldid=158351 5* 03RobinsAviary 5* (+125) 10Created page with "Hi! I'm Robin from Robin's Aviary!  I'm a programmer who is interested in making interpreters for various different esolangs."
> 1748024412 621771 PRIVMSG #esolangs :14[[07User:RobinsAviary14]]4 M10 02https://esolangs.org/w/index.php?diff=158352&oldid=158351 5* 03RobinsAviary 5* (+13) 10
< 1748024494 355934 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Fun fact: |> is used in GoogleSQL's somewhat recently introduced "pipe query syntax", which allows writing some otherwise quite unwieldy, nested-subquery-heavy SQL queries in a more "flat" form: https://cloud.google.com/bigquery/docs/reference/standard-sql/pipe-syntax
< 1748024512 286941 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :For example, you could write `SELECT f(z) AS z, SUM(y) AS y FROM (SELECT z, SUM(w) AS w FROM foo GROUP BY z) WHERE f(z) > 0 GROUP BY z` as `FROM foo |> AGGREGATE SUM(w) AS w GROUP BY z |> EXTEND f(z) AS fz |> WHERE fz > 0 |> AGGREGATE SUM(y) AS y GROUP BY fz AS z`.
< 1748024552 169792 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(Probably not the best example, but in practice for some actual queries that I can't share I've found it to be easier to follow.)
< 1748024553 74099 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I assume that EXTEND thing is part of the new syntax? I don't remember seeing it in SQL before
< 1748024603 602589 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and then Wolfram Mathematica decided to embrace this feature of literate programming and decided to take it further, allowing the programmer to write code that serves both as executable code and formatted as the sort of traditional mathematical notation that mathematicians are used to from traditional typography. so they added conveneitn ways to enter superscripts, subscripts, barred fractions, and 
< 1748024609 608354 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :surrounding square root signs, and stacked binomial coeff notation, and matrix writte as a 2d array of coefficients. And it also added lots of characters that mathematicians may use, like greek letters and ≥ and × but also four invisible infix operators. And I think that's why those four invisible characters are encoded in unicode.
< 1748024680 796639 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Yeah, `EXTEND` basically adds extra columns to the conceptual result table. It's pretty much the same as `SELECT` except it implicitly selects all the existing columns too.
< 1748024693 350207 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: didn't WITH syntax already existed for that in SQL?
< 1748024717 831873 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :maybe I don't understand what those SQL expressions that you gave as example mean
< 1748024749 6313 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the order in which you have to write things in standard SQL is weird
< 1748024772 535066 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think many people have observed that it would make more sense to put the columns being selected at the end and the table at the start
< 1748024773 610793 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :`WITH` defines named temporary tables. I guess it does have some similarity, in that you can also use it to avoid deeply nested subqueries.
< 1748024777 452597 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :WITH`? No such file or directory
< 1748024838 972140 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :WITH can also be used for recursive queries
< 1748024907 550378 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :``` hg cat -r 12479 /hackenv/wisdom/password # this was the point when I kind of gave up about SQL syntax
< 1748024911 657507 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :The password of the month is OFFSET 0 ROW FETCH NEXT 50 ROW ONLY.
< 1748025022 479464 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the semantics of SQL mostly make sense so I like that, but the syntax is terrible. of course I also think that about C+= and Rust to some extent.
< 1748025071 237700 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :I did have a number of queries that had the form of `WITH foo AS (SELECT ... FROM original_source ...), bar AS (SELECT ... FROM foo ...), baz AS (SELECT ... FROM bar ...) SELECT ... FROM baz ...`, but the pipe syntax removes the need to even give names for all the intermediate steps, for that sort of linear sequence of consecutive operations.
< 1748025085 522352 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw I actually prefer Rust's syntax to its semantics
< 1748025132 993451 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I am planning to write a very long article at some point as to why &mut is a misfeature (which sounds like a crazy statement, so I both need to back it up and present a viable alternative)
< 1748025221 86585 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :What does &mut mean in Rust?
< 1748025288 461540 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it is an exclusive reference: it's like a pointer to some memory but a) it's never null, b) it always contains a value of a particular type (and is statically checked to always contain a bit pattern that is valid for that type), and c) there's a compile-time-checked guarantee that nothing else will read or write the memory it points to until the reference ends
< 1748025324 146907 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and of Haskell too
< 1748025338 425977 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: I see
< 1748025356 873972 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :…and now I'm wondering how you forcibly end an &mut in Rust – for almost anything you can specify when the lifetime ends with mem::drop but that doesn't work for &mut for… reasons
< 1748025384 831658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think it's the only non-Copy type for which that is true
< 1748025551 190922 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the compiler is very good at inferring where it's supposed to end, though, so there is rarely a reason to end it manually)
< 1748025560 674437 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(There are probably other misfeatures in Rust as well; I think the main string type using Unicode is a misfeature in many programming languages, and I also once saw someone claiming that the fact that the string must be validated is a misfeature. I think there are probably others as well. C also has misfeatures, including some syntax misfeatures like I mentioned before.)
< 1748025619 192648 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :I think that the compiler should not always have to guess, and that specifying things manually would probably be helpful anyways
< 1748025621 737942 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :if you write that then I'll certainly want to read it
< 1748025630 207966 :impomatic!~impomatic@2a00:23c7:5fc9:5401:71af:7c8b:cf7b:1b45 QUIT :Ping timeout: 240 seconds
< 1748025767 724632 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :From what I understand of Rust (which is not much), such kind of exclusive references like that may be necessary to work with the general working of Rust, although that might itself be a problem, anyways, since maybe it is badly designed in general.
< 1748025928 520470 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Fun optimization story from #c the other day. Someone had a piece of code along the lines of (streamlining a little here) `struct foo { short x, y; }; bool f(struct foo *p) { return p->x == -1 && p->y == -1 }`, and it turned out Clang creates better code for it when the parameter declaration is changed to `bool f(struct foo p[static 1]) { ... }`. Presumably because for the first one, it has to
< 1748025930 774019 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :account for the scenario where `p->x` is a valid memory reference but `p->y` isn't, so the short-circuiting semantics of && become load-bearing, while `[static 1]` guarantees that an entire full `struct foo` object is accessible through the pointer.
< 1748026024 193400 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: I do like the approach of "a string is at the language level a list of codepoints, and the application can choose what the codepoints mean" – Perl does that, and allows the codepoints to go up to 2³¹
< 1748026048 206748 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(The generated code with the [static 1] parameter was also the moral equivalent of `(p->x & p->y) == -1`, which was kind of fun.)
< 1748026062 753355 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fizzie: apparently Rust has struggled with that sort of example in the past
< 1748026124 933089 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I read a blog post reading about how == on a struct with two fields didn't get optimised into one comparison at the time – then I tried it on a more recent version of Rust and it did
< 1748026132 953511 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so I wonder if it's putting in a [static 1] equivalent
< 1748026177 236910 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :ais523: I think that if you do that, then it should be useful to have a string type for 8-bit characters (which should probably the usual one) as well as one for 32-bit characters, and possibly also 1-bit characters is sometimes useful.
< 1748026245 127940 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :(Even in a string of 8-bit characters, you can have multi-byte characters and separate functions for dealing with them; for many uses this is probably the useful way to do it anyways, although there are also circumstances where having a type for a string of 32-bit characters is more useful.)
< 1748026260 174826 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :processors have similar short-circuiting issues, e.g. the "loop" opcode is very slow on modern processors because it a) has to handle the case of the branch target being paged out, and b) has to handle the case of the branch target being paged out on the last loop iteration
< 1748026293 933766 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which can lead to an awkward case where cx gets decremented and then you have a page fault in the middle of the instruction
< 1748026294 589424 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: oh wow. so if I define such a structure I should declare it alignas(4) which guarantees that if x can be read then y can be read as well?
< 1748026340 933995 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :modern processors would much prefer you to write dec cx; jnz label – because then they can handle the case of a page fault by just leaving the IP in between the two instructions
< 1748026370 12683 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it's parsed as a single instruction by the front end – the long encoding is just there to allow the IP to be left in the middle)
< 1748026370 615841 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I think that could also depend on the known alignment of the struct
< 1748026393 541153 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I don't know whether or not compilers optimise based on "if any address on a cache line is readable, then the entire cache line is readable"
< 1748026413 119903 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Yes, I think an alignment-based argument could also make it safe, although I was unable to convince Clang to make use of it.
< 1748026418 427728 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: it's circular too (I like to use the word co-evolution): since basically nobody uses the `loop` instruction anymore there's no incentive to deal with the complication you mentioned efficiently in the processor.
< 1748026422 790292 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in particular, I don't know of an architectural guarantee that cache lines won't be smaller in the future
< 1748026442 266988 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :If pages with memory access permissions are required to be aligned (and the compiler knows this), then I should expect that specifying required alignment should be allowed to work?
< 1748026446 452794 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which means that it could technically be incorrect to assume that
< 1748026453 488180 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Human-written code certainly does make that assumption sometimes.
< 1748026477 674802 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Specifically, string function implementations that read past the '\0' when they know they're working on aligned data.
< 1748026478 966283 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think there is a practical requirement to keep cache lines at at least 64 bytes, it would break a lot of code to make them smaller
< 1748026506 225924 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: this would be an architecture-dependent optimization, but that's fine because it's also architecture-dependent if you want to optimize to a single 32-bit comparison 
< 1748026533 765927 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: right, the question is as to what future processors may be the same architecture but have different caching mechanisms
< 1748026557 172261 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and obviously you should declare the type that way only if you relaly can guarantee that it's aligned, you can't slap it onto an existing type because that can break ABI-compatibility 
< 1748026577 106066 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :Is LOOP opcode sometimes used for stuff other than loops? (I had made VM codes that have a LOOP opcode and then often use it for stuff other than loops)
< 1748026579 273067 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :there are lots of examples of this sort of thing, e.g. is a processor that returns 0 for bsr on 0 a valid x86-64 processor?
< 1748026581 220051 :impomatic!~impomatic@109.181.213.27 JOIN #esolangs * :[https://web.libera.chat] impomatic
< 1748026606 654566 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: thanks btw, I had not considered the fact that there's no point between decrementing the loop counter and the conditional jump to be a complication.
< 1748026618 280805 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the Intel manual says it's undefined but Intel processors return the value that was in the output register beforehand, and AMD processors document it as returning the value that was in the output register beforehand)
< 1748026664 993036 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :zzo38: it could be, but nowadays it's rarely used for anything but codegolfing because it's so slow
< 1748026673 406229 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :compared to dec+jnz
< 1748026714 78417 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But I do not see that it is *necessarily* a costly complication; among all the other speculation and instruction reordering it feels like a pretty small thing. But add the fact that nobody uses the instruction and it makes sense that you punt on dealing with it.
< 1748026739 290275 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(efficiently)
< 1748026896 58622 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :FWIW, I didn't get Clang to make it a 32-bit comparison even with [static 1]. It removed the branching needed to avoid evaluating the other half, but even so still read the data as two 16-bit words. It also generated worse code for comparing "arbitrary" values than the all-bits-one ones. Here's an illustration: https://gcc.godbolt.org/z/P55zWqrnj
< 1748026972 824452 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :(Also tried slapping an `__attribute__ ((aligned (4)))` on it, but that did nothing.)
< 1748027035 47257 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: x86 in the broader sense does NOT guarantee that, because in 32-bit protected mode data segments that are less than 2**20 bytes long can have any length at byte precision. but x86-64 user mode guarantees trivial segmentation, so in x86-64 if part of any page (in the processor sense, not the operating system sense) is readable then the whole page is readable, and pages are 2**12 bytes or a 
< 1748027041 51996 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :multiple. an I/O device can break this but in C or rust you'd have to use a volatile read for those.
< 1748027108 277002 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Funny though... this week I rewrote an inner loop in assembly and it made it 2x faster. It was... unexpected. https://paste.debian.net/1376253/ (target is a Haswell processor)
< 1748027237 453155 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: it's surprising to see how much more the compilers spilled than you
< 1748027246 336024 :int-e!~noone@int-e.eu PRIVMSG #esolangs :yeah I thought so too
> 1748027329 644343 PRIVMSG #esolangs :14[[07Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=158353&oldid=126966 5* 03Kaveh Yousefi 5* (+904) 10Introduced an examples section comprehending as its two incipial members a repeating cat program and a Hello, World! printer.
< 1748027355 43916 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :one other weirdness is that the "lucky" g++ version appears to have multiple different targets to jump to from the loop, and the others have a single exit point
< 1748027363 502489 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: I'm never quite sure when x86 uses sign-extend versus zero-extend, but I think in your example code f2 which compares to -1 can use the shorter instruction encoding that has a one byte long immediate -1 in the instruction and sign-extends that to a short, and you can't do that when comparing to arbitrary
> 1748027388 678165 PRIVMSG #esolangs :14[[07Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=158354&oldid=158353 5* 03Kaveh Yousefi 5* (+612) 10Added a hyperlink to my implementation of the Brainfuck programming language on GitHub and supplemented the Implemented category tag.
< 1748027393 629456 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I actually took it one step further too, unrolling the loop one more time, which doesn't help on haswell but I did find a processor that executes the resulting loop in 3.5 cycles per iteration (EPYC Rome).
< 1748027444 683945 :fizzie!irc@selene.zem.fi PRIVMSG #esolangs :Well, the -1 case also ands the two halves of the struct together and performs just one comparison, that only works in the all-bits-one case of -1.
< 1748027462 446159 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: In the end I test each byte of the vector comparison individually. The "lucky" version omitted the bulk zero test and just does those individual ones.
< 1748027465 191948 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: true
< 1748027517 5531 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(each byte corresponds to one of the 8 byte values in the YMM register)
< 1748027587 298659 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: That's actually why I even looked at the assembly code... I /knew/ the value would be 0 almost all the time, so I did  if (!mask) continue; before testing the individual bytes. But for g++ that made the code slower and I had no idea why.
< 1748027608 634659 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: ah, I see, you are over-reading
< 1748027610 382100 :int-e!~noone@int-e.eu PRIVMSG #esolangs :value = resulting mask from the comparison
< 1748027622 640907 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in this case it shouldn't matter because you are over-reading from a set of integer registers
< 1748027628 279858 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but it may be hard for compilers to figure that out
< 1748027657 224451 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: yeah, anything like strcmp/strscn/strlen that you implement with vpmovmskb is exaclty a kind of code where I would expect that writing it in assembly (or calling a lower level library function implemented in hand-written assembly) will help
< 1748027716 213790 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I guess this is more like strnscn
< 1748027719 337849 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: anyway, I /tried/ to help the compilers by writing the exact inner loop I wanted but they still spilled the register contents all over the place.
< 1748027727 93716 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :or strcscn or whatever it's called
< 1748027728 553178 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I eventually ended up finding a better algorithm, but for a while a program I was writing had a branch that was only 1 in 4 billion to be taken (it required an effectively random 32-bit number to have a particular value), and yet it had to be there for correctness
< 1748027745 978417 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Conclusion: Compilers still are kind of stupid, and *sometimes* it can really hurt.
< 1748027751 833041 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I thought "I should probably put an unlikely annotation on this, once those get stabilised in Rust)
< 1748027755 834918 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :no, neither
< 1748027778 932870 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(it would have mattered because the check was short-circuitable but it looked unpredictable to LLVM, so it didn't try to short-circuit)
< 1748027993 917202 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: over-reading... vpmovmskb wants a 64 bit destination argument, and I wanted to let the compiler assign the register. I don't know whether there's a magic incantation to get %eax from %rax, nor whether that would make any difference
< 1748028106 726433 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Anyway. It's atypical code, and when I wrote the inline assembly I was hoping for maybe 20% faster code, not 2x faster. :-)
< 1748028143 437512 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I had not actually computed cycle counts at that point, just observed a very high variance in runtime from different compiler outputs.)
< 1748028205 717541 :int-e!~noone@int-e.eu PRIVMSG #esolangs :May I add that from a 90's person perspective the idea of executing 9 instructions in 2 cycles is insane. :-)
< 1748028265 133555 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :The Thing King! https://en.wikisource.org/wiki/Paging
< 1748028268 858667 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I am easily amused
< 1748028371 558177 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: true
< 1748028543 993460 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Sgeo: So they implemented this in a Thing King Machine?
< 1748028592 280089 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :<int-e> I don't know whether there's a magic incantation to get %eax from %rax, nor whether that would make any difference ← gcc has one of those for inline asm and I think Rust does too
< 1748028593 689441 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: doesn't calling a #[cold] function work as an unlikeliness annotation? (or raising a panic, but that's probably not appropriate in your case.)
< 1748028594 103618 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(The timing doesn't quite work out: https://en.wikipedia.org/wiki/Thinking_Machines_Corporation was founded in 1983)
< 1748028624 257440 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: probably, but it also has other side effects
< 1748028643 693303 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok
< 1748028691 645021 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :likely/unlikely/cold_path seem fairly close to stablisation, I think the main concerns were based around whether all three functions were needed and what exactly the semantics were
< 1748028716 660335 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure how much discussion there was of whether an unpredictable was needed
< 1748028784 980342 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ok
< 1748029278 352630 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :in general, though, compilers are very bad at vectorising things that are even slightly nontrivial and I'm not completely sure why
< 1748029316 712470 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I have plans to go the other way – a language in which you can *only* write code that vectorises well, and a compiler for it that gives guaranteed efficient vectorisation
< 1748029490 833572 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yeah, I was thinking of something like that, a low-level array programming language
< 1748029522 274951 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :though that still leaves lots of choices open so I may be thinking of something very different from you
< 1748029528 892399 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, I realised after a while that I was supposed to give it APLish semantics where the program is written as though it's a linear sequence of operations on arrays
< 1748029546 352653 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :even though it optimises into a fused loop
< 1748029554 151507 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Ah. The keyword is "operand modifier". The particular incantation is that "%k0" gives you %eax when %0 is rax. Or "%h0" gives you %rax from %eax though I guess that's theoretically dangerous.
< 1748029592 766101 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: writing to %eax zeroes the rest of %rax, so the theoretical danger could be avoided by setting the high part to 0 when you're done
< 1748029623 973993 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :processor designers seemed to have realised that "writing to the low part of a register zeroes the high part" gradually
< 1748029642 711591 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :*that "…" is more efficient
< 1748029683 684985 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, something that confuses me – writing to an xmm register with SSE instructions leaves the high part of the corresponding ymm alone, whereas writing to it with AVX instructions zeroes the rest of the ymm
< 1748029709 248387 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but AVX and ymm were introduced at the same time, weren't they? so why even bother to give the older commands slow behaviour when mixed with the newer ones?
< 1748029713 259211 :int-e!~noone@int-e.eu PRIVMSG #esolangs :anyway, testing just %eax makes no difference to the runtime here
< 1748029736 331765 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I didn't expect any)
< 1748029759 82713 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hacks like vzeroupper were introduced to paper over the mess, but there are still a number of different ways that processors try to optimise it, none of which are really satisfactory, and it makes ABIs slower as well
< 1748029801 783480 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: the problem is that there's a tradeoff here. if writing to the low part zeroes the high part, that's more efficient and easier to write ordinary functions in. but it also makes it harder to be compatible with a program written for an earlier version of the architecture, because when the older code tries to save and restore a callee-save register then it will accidentally zero the upper part of 
< 1748029807 789246 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :its register.
< 1748029870 709531 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: oh, I see, it's so that programs that use avx2 can call sse subroutines without breaking things, if there are call-preserved vector registers
< 1748029915 65139 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, I think that combination is normally forbidden anyway because processors are so slow at doing the register merge – the x86-64 ABI bans letting SSE code ever see the high half of a ymm as nonzero
< 1748029927 431870 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :this is why in x86, the SSE2 instructions don't change the high part of YMM registers, but the similar AVX instructions that still act on just the lower 16 bytes of a YMM register zero the upper part of the YMM register, because any compiler that emits the AVX encoding knows how to save and restore all 32 bytes
< 1748029929 334426 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: an unlikely annotation does help clang out quite a bit; g++ doesn't do anything useful with it.
< 1748029937 164395 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :meaning that you have to call vzeroupper on function return if you use any avx2, and in turn meaning avx2 registers can't be call-preserved
< 1748029958 837972 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :right, I see the reasoning
< 1748029964 397087 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :compatibility at the cost of performance
< 1748029983 34610 :int-e!~noone@int-e.eu PRIVMSG #esolangs :clang manages to produce a 3 cycle version of the inner loop with the annotations.
< 1748029989 784767 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but the compatibility cases got soft-banned by the people who standardised the ABI
< 1748030069 558661 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and I guess  https://paste.debian.net/1376259/ looks decent; no more spills
< 1748030092 937461 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :120457(%rbp)?
< 1748030104 557313 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :oh, it's an integer addition, not a pointer addition
< 1748030110 784511 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's just using the pointer addition command
< 1748030120 989871 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: yes, but that "soft-banned" just means that YMM registers can never be callee-saved, even though you could probably write/compile more efficient code if you had a few callee-saved ones
< 1748030140 230764 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the use of %rbp caught me out because I initially assumed it was on a really big stack frame
< 1748030148 547112 :int-e!~noone@int-e.eu PRIVMSG #esolangs :related to the loop upper bound
< 1748030154 973508 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but of course that would use a negative numbr
< 1748030182 74924 :int-e!~noone@int-e.eu PRIVMSG #esolangs :hmm actually
< 1748030187 72974 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :MMX was even worse in this respect, but fortunately nobody wants to use MMX much anyway for other reasons too, so it doesn't matter
< 1748030203 345514 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :the use of xor rather than cmp is really weird, even though it shouldn't matter – I assume that's for the benefit of the code after the loop
< 1748030229 883368 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think MMX is top of the list of "never use this vectorising mechanism" for most people who hand-vectorise
< 1748030253 528309 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: I'm missing two more instructions: https://paste.debian.net/1376260/
< 1748030260 230389 :int-e!~noone@int-e.eu PRIVMSG #esolangs :misread a label
< 1748030264 410139 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :no, technically 3Dmax is on the top of that list
< 1748030287 201039 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but that's kind of cheating
< 1748030290 468688 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and /previously/ clang++ combined the two conditions into a single one and the arithmetic looked vaguely complex enough for that
< 1748030292 381526 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :didn't a few 3Dmax! instructions get stolen and become part of some other instruciton set?
< 1748030307 935673 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I don't know
< 1748030308 250449 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :hmm, or was it called 3Dnow! ?
< 1748030313 903687 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, that
< 1748030318 494650 :int-e!~noone@int-e.eu PRIVMSG #esolangs :3Dnow! was a thing
< 1748030320 799238 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so irrelevant that I don't even remember its name
< 1748030336 390152 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :does it really have an exclamation mark like CorelDraw! and Irregular Webcomic!? 
< 1748030341 227154 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I think so
< 1748030353 642984 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :yes (just looked it up)
< 1748030381 514518 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: it is kind of funny that that `lea` is in there... it could be done outside of the loop
< 1748030456 115084 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and I guess those two lea-s make the difference between 3 cycles and 2 cycles
< 1748030458 774239 :int-e!~noone@int-e.eu PRIVMSG #esolangs :still, decent
< 1748030466 838061 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :looks like MMX is integer arithmetic and 3Dnow! is float arithmetic, both in mm registers
< 1748030586 683204 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: there are 10 instructions there and most modern Intel compilers decode at the rate of 4 per cycle, so that would explain the 3-cycle performance
< 1748030596 814556 :int-e!~noone@int-e.eu PRIVMSG #esolangs :g++ does this and I don't even know where it found so many registers to add 4 to in the inner loop. https://paste.debian.net/1376262/
< 1748030614 994506 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: you meant CPUs :)
< 1748030621 516723 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I did
< 1748030667 290161 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :nice, that could be funny for legal problems as in https://www.youtube.com/watch?v=_8xhdL8BPvU&t=427s “Side note. I particularly enjoyed how since the title of <i>Sharks!</i> includes an exclamation mark, so too must all these legal documents, which was funny every time I read it. SHARKS!”
< 1748030714 195092 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Hmm, do you know whether the x86_64 ABI requires the upper 32 bits to be 0 for 32-bit values passed in registers?
< 1748030729 174617 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(otherwise I'll check)
< 1748030740 275783 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(SysV ABI of course)
< 1748030740 435433 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: I did once but can't remember
< 1748030763 460734 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: I don't think they can decode 4 instructions per cycle when there's so many vector instructions involved, and it shouldn't matter in a short inner loop because the decoded form will be cached in like two or three different ways
< 1748030855 973992 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: check in Agner's documentation, that's more readable than the original ABI descriptions
< 1748030923 276340 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ouch, apparently the SysV ABI says that for booleans, the bits above the bottom 8 are unspecified when used as an argument or return value, but the high 63 bits have to be 0 in other situations
< 1748030937 343184 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm not sure what the difference is or even what other situations might matter
< 1748030989 958805 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: indeed, caching is possible – I was wondering whether it might also be bottlenecked by compute units, but it's hard to calculate that in my head
< 1748031011 351184 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :on Intel there are four compute units but not all of them can handle all operations (and one of them only does very simple integer arithmetic like adds and compares)
< 1748031221 420565 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: so I've checked twice and haven't seen where the ABI talks about the high bits of registers, except for booleans and long double
< 1748031414 188361 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :<ais523> I'm not sure what the difference is or even what other situations might matter ← I figured it out, if there are so many arguments that booleans have to be passed using the stack, they're given 8-byte stack slots and those have to be encoded as 0LL or 1LL
< 1748031542 642499 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: Yeah I don't see any guarantee either so I guess the top bits are arbitrary.
< 1748031623 469581 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: if you want to write a boolean into a GP register or memory word, you'll often do it with the 386 SETcc instructions, and those write just one byte, whereas if you're returning a 32-bit integer into a register you'll usually write it with an instruction that zeroes the upper 32 bits 
< 1748031633 598892 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :compilers seem to generate code that makes no assumptions about the top bits of the arguments that functions receive
< 1748031646 148925 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: did you mean to ping me there
< 1748031661 894226 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :probably both of you
< 1748031686 849429 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, you ais523 brought up the booleans specificaly
< 1748031690 404323 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :s/aly/ally/
< 1748031846 358634 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: Yes I realize that the upper half is *usually* cleared anyway because that's what the CPU does (to reduce data dependencies).
< 1748031847 81813 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :do we have a HackEso command to convert asm to machine code?
< 1748031866 303155 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`` ls -1 bin/ | grep as
< 1748031870 398196 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :No output.
< 1748031877 282491 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`` ls -1 bin/
< 1748031879 129247 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :No output.
< 1748031884 802187 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`` ls -1 /hackenv/bin/
< 1748031886 312318 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :​ \  \  \ ! \ " \ # \ ' \ ( \ : \ ? \ ?? \ @ \ ^.^ \ ` \ `^ \ `` \ ¿ \ ؟ \ ⁗ \ 🌱 \ `̀ \ 04w08e09l11c12o13m04e \ ,1 \ 1 \ 13 \ 1492 \ ,2 \ 2 \ 2014 \ 2015 \ 2016 \ 2017 \ 3 \ 4 \ 5 \ 5quote \ 5w \ 8-ball \ 8ball \ aaaaaaaaa \ acronym \ addquote \ addscowrevs \ addtodo \ addwhatis \ age \ aglist \ airport \ airport-lookup \ allquotes \ analogy \ anonlog \ append \ as86 \ as-encoding \ asm \ asmbf \ asmbfx \ autowelcome \ bconv \ beat \
< 1748031914 209375 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`` cat /hackenv/bin/as-encoding
< 1748031915 784324 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :echo "$1" | as -o /tmp/out.o - && objdump -d /tmp/out.o | grep -P '^ *[0-9a-f]+:' | sed 's/^[^\t]*\t//; s/ *\t/: /g'
< 1748031922 101644 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :that looks promising
< 1748031961 243076 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :`as-encoding prefetch (%rsi)
< 1748031964 534866 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :0f 0d 06: prefetch (%rsi)
< 1748031983 602412 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :OK, so that *was* a 3Dnow! instruction, but apparently the encoding was changed
< 1748031995 755403 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :to no longer be in the 3Dnow! namespace
< 1748032668 806448 :visilii_!~visilii@213.24.132.221 JOIN #esolangs * :ZNC - https://znc.in
< 1748032674 903679 :visilii!~visilii@213.24.134.172 QUIT :Ping timeout: 268 seconds
> 1748034053 291873 PRIVMSG #esolangs :14[[07Talk:CAPI14]]4 10 02https://esolangs.org/w/index.php?diff=158355&oldid=155039 5* 03Tommyaweosme 5* (+202) 10
> 1748034094 532657 PRIVMSG #esolangs :14[[07Talk:CAPI14]]4 M10 02https://esolangs.org/w/index.php?diff=158356&oldid=158355 5* 03Tommyaweosme 5* (+21) 10
< 1748034250 931865 :sprock!~sprock@user/sprock QUIT :Remote host closed the connection
> 1748034443 643359 PRIVMSG #esolangs :14[[07Countable infinity is uncountable infinity14]]4 N10 02https://esolangs.org/w/index.php?oldid=158357 5* 03Tommyaweosme 5* (+402) 10Created page with "If we write all the numbers big-endian, like 0,1,2,3,4,5,6,7,8,9,01,11,21... then put a decimal point before it and put all the numbers before that, like 0.0, 0.1, 0.2... 0.01, 0.11.. 1.0, 1.1... then since infinity squared is stil
> 1748034458 727587 PRIVMSG #esolangs :14[[07Countable infinity is uncountable infinity14]]4 M10 02https://esolangs.org/w/index.php?diff=158358&oldid=158357 5* 03Tommyaweosme 5* (+20) 10category
> 1748034492 926223 PRIVMSG #esolangs :14[[07Countable infinity is uncountable infinity14]]4 M10 02https://esolangs.org/w/index.php?diff=158359&oldid=158358 5* 03Tommyaweosme 5* (+10) 10
> 1748034543 785294 PRIVMSG #esolangs :14[[07Talk:Countable infinity is uncountable infinity14]]4 N10 02https://esolangs.org/w/index.php?oldid=158360 5* 03Ais523 5* (+370) 10explain why this is wrong
> 1748034618 503695 PRIVMSG #esolangs :14[[07Talk:Boltzmann brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=158361&oldid=158309 5* 03Tommyaweosme 5* (+361) 10
> 1748035679 408609 PRIVMSG #esolangs :14[[07Talk:Countable infinity is uncountable infinity14]]4 10 02https://esolangs.org/w/index.php?diff=158362&oldid=158360 5* 03Tommyaweosme 5* (+364) 10
< 1748035823 536143 :int-e!~noone@int-e.eu PRIVMSG #esolangs :...another person confused by the difference between "arbitrarily long" and "infinitely long"
< 1748035826 888016 :tromp!~textual@2001:1c00:3487:1b00:30a6:c51d:9dbb:1dc5 QUIT :Quit: My iMac has gone to sleep. ZZZzzz…
< 1748035851 955934 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but I hate for it to take place on a wiki of all places
> 1748035871 594316 PRIVMSG #esolangs :14[[07Talk:Countable infinity is uncountable infinity14]]4 10 02https://esolangs.org/w/index.php?diff=158363&oldid=158362 5* 03Ais523 5* (+303) 10p-adic numbers are only countable due to repeating  if you include nonrepeating numbers in the same style, there are uncountably many
< 1748035883 918320 :int-e!~noone@int-e.eu PRIVMSG #esolangs :s/take place/happen/ (hate the word near-duplication)
> 1748036051 774991 PRIVMSG #esolangs :14[[07Talk:Boltzmann brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=158364&oldid=158361 5* 03Int-e 5* (+128) 10scnr
< 1748036108 796243 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(I really shouldn't have because it'll just act as troll fodder.)
< 1748036666 618316 :ais523!~ais523@user/ais523 QUIT :Quit: quit
> 1748036714 718749 PRIVMSG #esolangs :14[[07Game of Life14]]4 10 02https://esolangs.org/w/index.php?diff=158365&oldid=154058 5* 03Corbin 5* (+222) 10/* History */ Context for Gosper's 1970 construction, as related by Conway to Simon Peyton Jones.
< 1748037558 105042 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: hold on, let me grab my mono-white infinite lifegain combo deck
< 1748038069 677519 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :`olist 1326
< 1748038073 289031 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :olist <https://www.giantitp.com/comics/oots1326.html>: shachaf oerjan Sgeo boily nortti b_jonas Noisytoot
< 1748038177 621264 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :I saw it, but completely forgot about olisting
< 1748038360 219374 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sometimes I forget too
< 1748038363 491298 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Trying to recall when I've did pseudomathy stuff. Um, believing 2/0 = 4/0 != 3/0, shortly before instead watching all x/0 except 0/0 collapse into the same thing.
< 1748038424 674995 :Sgeo!~Sgeo@user/sgeo PRIVMSG #esolangs :Trying to define a number @ such that |@| = -1, but |x| is a ... definitions thing, not so much a function that can be easily extended to new kinds of numbers without definitions anyway, I... think?
< 1748040695 918576 :sprock!~sprock@user/sprock JOIN #esolangs sprock :maeve (she/her)
> 1748042064 839137 PRIVMSG #esolangs :14[[07User:Tommyaweosme/awesomenet website format14]]4 N10 02https://esolangs.org/w/index.php?oldid=158366 5* 03Tommyaweosme 5* (+584) 10Created page with "awesomenet website format (awf) is a modified version of html used for awesomenet (found at https://docs.google.com/document/d/1sOSj-Gv6Kyu4DLou2aGoTioKh7beHmfx_fe5kCCsRUM/edit?usp=sharing). == commands ==  <h<b></b>1>a</<b></b>h1
> 1748042449 142011 PRIVMSG #esolangs :14[[07Talk:Countable infinity is uncountable infinity14]]4 10 02https://esolangs.org/w/index.php?diff=158367&oldid=158363 5* 03Tommyaweosme 5* (+231) 10
> 1748042497 895416 PRIVMSG #esolangs :14[[07Countable infinity is uncountable infinity14]]4 10 02https://esolangs.org/w/index.php?diff=158368&oldid=158359 5* 03Tommyaweosme 5* (+101) 10
> 1748043121 680925 PRIVMSG #esolangs :14[[07User:Tommyaweosme14]]4 10 02https://esolangs.org/w/index.php?diff=158369&oldid=158202 5* 03Tommyaweosme 5* (+30) 10
< 1748043734 757584 :amby!~ambylastn@ward-15-b2-v4wan-167229-cust809.vm18.cable.virginm.net QUIT :Remote host closed the connection