< 1566086727 292305 :andrewtheircer!b2dd15f4@gateway/web/cgi-irc/kiwiirc.com/ip.178.221.21.244 PRIVMSG #esoteric :e < 1566088376 72465 :andrewtheircer!b2dd15f4@gateway/web/cgi-irc/kiwiirc.com/ip.178.221.21.244 QUIT :Remote host closed the connection < 1566088696 552153 :b_jonas!~x@catv-176-63-24-72.catv.broadband.hu QUIT :Ping timeout: 272 seconds < 1566088722 226295 :b_jonas!~x@catv-176-63-24-72.catv.broadband.hu JOIN :#esoteric < 1566090663 596649 :b_jonas!~x@catv-176-63-24-72.catv.broadband.hu QUIT :Remote host closed the connection < 1566091251 866192 :FreeFull!~freefull@defocus/sausage-lover QUIT : < 1566091534 500606 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1566091549 114189 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ugh, I'm dealing with a really annoying missed optimisation atm < 1566091552 684976 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ptrdiff_t notneg(unsigned char b) { if (b <= 0xC0) __builtin_unreachable(); return -(ptrdiff_t)(unsigned char)~b; } < 1566091740 473652 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the correct optimisation is «return 1 + (ptrdiff_t)(signed char)b;» but neither gcc nor LLVM finds it (you could also do the increment first) < 1566091957 212544 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :huh, they don't find it even with a cast to signed char in there, although clang finds it if you put a cast to signed /int/ in there (of course, none of these casts make a difference because ~b has to be a positive number in the 0..30 range) < 1566091996 841070 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :LLVM allows you to specify the range, but I think only for loading from memory. < 1566092105 474244 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I just get annoyed when compilers produce asm that's worse than the asm I'm expecting < 1566092130 652504 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(and I'm the sort of person who actually checks that when I write code like -(ptrdiff_t)(unsigned char)~b…) < 1566092177 566308 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Is there any command to have a inline LLVM code in a C code? < 1566092223 178968 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Also, in Ghostscript, the "forall" command doesn't seems to work properly for strings longer than 800 bytes. (Other commands work (including the "length" command), and it works fine for arrays, but not for strings.) Why does it do that? < 1566092309 51714 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's no standard C method to use inline LLVM; clang could theoretically support it as an extension to __asm__ but I don't think it does < 1566092419 637995 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, so my next problem is, should I write it as 1 + (ptrdiff_t)(signed char)b in the original source, even though that's a lot less clear (the operation I'm using is conceptually a combination of a bitwise-complement and a unary minus, the fact that that does the same thing as an increment is just an intentionally engineered coincidence) < 1566092565 206381 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Oddly enough if you write out a lookup table gcc finds a good implementation. < 1566092699 64536 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what, if you special-case all 31 possible inputs? :-D < 1566092728 935559 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, if you write a switch over the entire range. < 1566092781 420364 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(I mean "range of inputs" and not "codomain" or "image", which people refer to as "range" for some reason.) < 1566092825 428959 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :One possibility is to write a comment. < 1566092875 830426 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(Also, which implementation is better might depend on the target computer, maybe?) < 1566092913 919364 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What's the context of this function? < 1566092925 868872 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :decoder for a file format < 1566092953 917496 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it stores references to earlier locations in the file as 1, 2, 4, or 8 bytes, I'm writing a separate function for each < 1566092961 792548 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And the speed of this operation is relevant? < 1566092965 37736 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the references are bitwise-complemented < 1566092991 213581 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the format's designed to be extremely fast, faster to use a memory image of the format than actually parsing it < 1566093012 696781 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, which format is it? < 1566093015 414224 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this operation needs to be able to compete with pointer dereferences to do that < 1566093021 647001 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's a format I'm inventing atm < 1566093034 878615 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Aha. < 1566093062 790665 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the idea is that the +1 ends up getting inlined into the dereference of the resulting pointer) < 1566093113 907414 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'd store the offsets as with the +1 added if I could, but I can't because 0 is a valid offset and there is a fairly esoteric constraint that the offsets cannot be valid UTF-8 < 1566093135 848492 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :#esoteric is definitely the right channel for this :-D < 1566093151 866792 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So that's the reason for the 0xc0. I was vaguely wondering before whether it was related to UTF-8. < 1566093168 7604 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What's this for? < 1566093179 240299 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe you're being deliberately vague. < 1566093208 539014 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :not because it's secret, mostly because it's hard to explain < 1566093230 213971 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the format's designed for the output of a parser, i.e. the in-memory representation of a parse tree < 1566093250 60073 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but to be generic enough to be usable in much the same situations as XML is < 1566093290 131704 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the idea is that the parser output is just an image in memory, it's not something that you parse into a linked tree of structures like you normally do < 1566093326 648458 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :linked lists are bad performance-wise, and linked trees are very common but probably also beatable in performance for the same reasons, so I wanted to try < 1566093377 200631 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :XML is often used in cases where it shouldn't be, anyways, I think < 1566093379 662638 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That makes sense. < 1566093404 32006 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I suspect the gains from a more efficient memory encoding are way bigger than the gains from a couple of extra instructions to dereference a pointer. < 1566093407 321704 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: yes < 1566093420 420619 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: that's what I'm hoping, at leasts < 1566093452 9176 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(not just more efficient, but more compact too, meaning it makes better use of the cache; also less malloc overhead) < 1566093519 124309 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it's plausible that even with a regular parser, you should have only one or a few calls to malloc for the entire tree, which you free all at once. < 1566093544 50665 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :There isn't much benefit to mallocing individual nodes. < 1566093633 829428 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :all the parsers I've seen so far malloc individual nodes for the output tree, although I agree there isn't much benefit to it < 1566093646 840984 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think the idea is to let you free parts of the tree individually < 1566093677 847376 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I suspect there's no real idea, it's just that people learn that that's how you get memory. < 1566093681 930455 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the normal operation on a tree is to traverse it, and that lets you build a new tree as you go < 1566093734 48911 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :In some programs you would free one branch of the tree separately from the rest < 1566093736 293089 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this program is actually being written in Rust (I translated it into C to test it on gcc), and rust has a #[no_std] annotation that means your program has no support at all from the operating system, it's used for purely algorithmic libraries < 1566093791 149224 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that means you don't get memory allocation unless the caller gives you a memory allocation callback, and so I try to avoid allocations out of habit, thinking carefully about if I need them < 1566093799 328904 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :often, I don't need much more than one or two for the program < 1566093818 441798 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'd like to know more about possible allocation strategies. < 1566093852 161045 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think I've talked about that in here before. < 1566093869 902381 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, the one I'm working on for this program (for the parsers, tree operations, etc.) is a purely linear allocation strategy where everything is written in memory left to right in order, meaning that your algorithms have to be able to manage that < 1566093911 204153 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Does this memory go left to right in order of increasing addresses? < 1566093913 908071 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :many algorithms can't, but for a parser it's fairly hopeful because parsing algorithms and tree-traversal algorithms both naturally work like that < 1566093948 120046 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, increasing addresses (decreasing is possible I guess but it's sufficiently alien that you normally get less support from the standard library, OS, processor, etc.) < 1566093975 215425 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Unless it's the call stack. < 1566093988 933586 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :writing left to right unfortunately means that reading right to left is sometimes required, but reads on a parse tree are generally more random-access than writes as it is (you're often trying to match both branches of the tree to something) < 1566093996 730420 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I like the idiom of having a global (or thread-local) arena that can be used effectively as a stack but with the frames manually managed. < 1566094003 244867 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the call stack in x86 is the wrong way up and I am very upset at this < 1566094047 745517 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So functions that produce variable-size output that's only needed briefly can just write into there. < 1566094052 201305 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :E.g. sprintf. < 1566094053 528129 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I wrote one program which needs the caller to specify a memory allocation function, although you can just put realloc and it will work, which is normally what would be done, I think. < 1566094059 83529 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's one /really big/ technical advantage to having the call stack the other way round, which is that in x86, overflows beyond the end of a stack-allocated array overwrite the function's return address by default, which is just about the worst possible thing to overwrite < 1566094085 932745 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I've heard that brought up as a security benefit and I don't really buy it. < 1566094098 84155 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :In some instruction sets the call stack is not addressable < 1566094102 262876 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if the call stack goes the other way, the situations in which that happen are much less common, requiring you to be writing to an array of a function which called the current one < 1566094116 412752 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, having a separate call stack and data stack is a much better idea for multiple reasons < 1566094120 120461 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :char buf[n]; sprintf(buf, "%s", ...); seems pretty common to me. < 1566094129 853301 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, I agree that that makes more sense. < 1566094191 633384 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: well, that example is broken regardless of which way up the stack goes (although with a stack that goes upwards, sprintf would at least be able to detect that something was wrong; it knows where its own return address is in memory, but not where its caller's is) < 1566094214 670074 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :yea.. that seems like a security /issue/ < 1566094217 132721 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure if anyone would write sprintf like that, but maybe they would < 1566094218 857502 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that's bad < 1566094229 471027 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :in fact, that's exactly how ROP works < 1566094241 507835 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Or, I mean, char buf[n]; gets(buf); or whatever. < 1566094267 549026 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Many of the classic buffer overflow problems involve calling another function so changing the stack direction doesn't help much. < 1566094268 392675 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: well, ROP is one of the most effective ways to exploit this, but the exploit isn't ROP, it's just that the exploit lets you use ROP < 1566094290 204812 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :gets should be simple enough to be inlined < 1566094306 40817 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :also thumbs-up for using rust. If you're trying to allow custom allocators, use what is already provided < 1566094308 448067 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I would be pretty surprised if gets was inlined. < 1566094321 404682 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Rust seems to be pretty bad at custom allocators or unusual allocation strategies. < 1566094325 86612 :botnick!~botuser@bl14-199-237.dsl.telepac.pt JOIN :#esoteric < 1566094340 164714 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so would I, mostly because that function is such a bad idea that I doubt much effort has been put into optimising it < 1566094354 881421 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure if Rust's #[global_allocator] is stable yet, but that makes custom allocators very easy < 1566094369 64681 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unusual allocation strategies are IME either very easy or very hard < 1566094377 269440 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :mmm.. < 1566094386 101899 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think the main reason I think that is that Rust is all about destructors, which muddle deallocation with other code. < 1566094390 37149 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :i thought rust's allocation choice could be done per function < 1566094391 395459 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :guess not < 1566094395 459378 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :i mean < 1566094397 399365 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :i see why < 1566094426 493457 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, the issue there is not so much allocation but deallocation < 1566094439 364385 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :shachaf: there is the Drop trait, which can be useful. Could possibly implement a trait that keeps tabs on what allocator was used to make a object < 1566094439 988495 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Unfortunately those issues are connected. < 1566094446 613175 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, it wouldn't be too hard to give the various allocators their own portions of address space and use the pointer value to tell them apart < 1566094472 716023 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I feel like you just want to do the right thing statically. < 1566094479 141823 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :btw, separately from this project, I had an idea about a very eso allocation strategy < 1566094485 215420 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :oooo < 1566094491 335037 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you're adding a bunch of dynamic behavior like that there should be a good reason for it. < 1566094497 129480 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the idea was that all the pointers in the entire program would be doubly-linked < 1566094513 73344 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like, to point from one object to another, you need to point to a pointer field that points back at you < 1566094520 417583 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :i think the cache would commit suicide < 1566094540 669694 :botnick!~botuser@bl14-199-237.dsl.telepac.pt QUIT :Read error: Connection reset by peer < 1566094543 574195 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now, the great thing about this strategy is that you can move objects around in memory at will < 1566094549 783730 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :i mean < 1566094552 417864 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because you already know where all the inbound pointers are and can just update them < 1566094555 704309 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that's the strategy a lot of VMs use < 1566094557 439612 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :like the JVM < 1566094577 860960 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, I was inspired by compacting garbage collectors, the idea was to do the same thing without a GC < 1566094590 945014 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure if this is useful, and it probably isn't, which is why I described it as very eso < 1566094611 291760 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :reducing memory fragmentation could be useful if you keep memory organized at the same time < 1566094621 897699 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :and do a bit of the memory usage predictor's work for it < 1566094626 63976 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Did you see that malloc that merges pages which don't have overlapping allocations? < 1566094627 746615 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, this is one of those cases where the advantages are clear but the disadvantages are terrifying < 1566094631 747201 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: yes < 1566094654 152772 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :at first I thought "surely that isn't necessary", but then came up with some pathological programs where it is < 1566094677 785088 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think my current attitude is that if your program is doing zillions of little mallocs and frees everywhere it's probably doing things badly anyway. < 1566094685 872747 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :^ < 1566094694 873715 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. imagine a program that allocates 100 million 8-byte objects, deallocates 99 out of every 100, then allocates 1 million 800-byte objects < 1566094700 987788 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :if it comes to that, use a slab allocator for some of those objects < 1566094722 913210 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :assuming they're all uniform < 1566094736 390223 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my thoughts on the matter is that the only difficult case is what happens if a program deallocates a lot of small objects, then needs to allocate large objects that are too large for the remaining spaces < 1566094761 594487 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :all the other cases are trivial by comparison < 1566094796 150898 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't think this is a remotely common pattern for long-running interactive applications, but I can see a batch process doing something like that when moving on from one phase of computation to another < 1566094813 523836 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I think Dwarf Fortress has an issue with that < 1566094818 81897 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :albet with larger objects < 1566094820 55568 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe, if you have a random malloc pattern, there should be some sort of compaction phase whenever your program shifts modes < 1566094861 869383 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :in The Powder Toy everything is preallocated because malloc pauses are unacceptable < 1566094869 738872 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, this is what inspired the "everything is doubly-linked" idea because it's one of the only ways, short of a GC, to solve the problem < 1566094890 741000 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(that said, preventing the problem happening in the first place by using a more predictable malloc/free scheme is probably better!) < 1566094917 507975 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :If you know the max number of objects, then just allocate that, the linux kernel won't mind < 1566094930 990417 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: are they preallocated /and/ prefaulted? < 1566094958 827484 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :not prefaulted, but they generally get faulted very early in the app's lifespan so it's not an issue < 1566094961 234003 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :animalloc doesn't have any pauses other than page faults, and those will happen even with a preallocation strategy unless you prefault all your pages too < 1566094976 569266 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :could add prefaulting for fun < 1566094991 204319 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Did you know that merely reading from an mmapped page in Linux will only fault it in as a CoW zero page rather than giving you your own memory? < 1566094996 9996 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: it's one line of code < 1566095001 989555 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: yes < 1566095015 634560 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ais523: and that is? < 1566095058 855108 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually I'm wrong, I thought madvise could do it on arbitrary memory, but the most aggressive prefault it supports is a request to preload into /cache/ faster < 1566095082 238247 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ok nvm it is prefaulted, we run the simulation clear no matter what < 1566095093 233716 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mmap can do it with MAP_POPULATE but that requires you to actually be getting the memory from mmap < 1566095094 315417 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :so the action of wiping the sim should cause prefaulting < 1566095121 651036 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :as we technically "use" the memory < 1566095143 372748 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…why are mmap and madvise not synchronized in what requests they support < 1566095188 644536 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :..prolly should work on reducing allocations in the game's graphics < 1566095212 404710 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :the sim is effectively malloc free < 1566095219 19140 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :but graphics are pretty CPU hungry too < 1566095279 517020 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :..gah < 1566095287 571821 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :we still haven't squashed the malloc in INST code < 1566095307 937549 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, I've now implemented the 1, 2, 4, and 8 byte versions of this function < 1566095336 379054 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the -~ gets optimized to +1 only in the 8-byte case (presumably because LLVM can't optimize the - movzx ~ sequence when the number is known to be negative) < 1566095456 314065 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one interesting thing is that the optimizer implements the comparison with 0xC100000000000000 using a 56-bit shift and a comparison with 0x000000C1; I can believe that all those leading zeroes are actually fastest, but think there miight be a better way < 1566095494 730939 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that sounds like it would be faster on Nephelem era CPUs, but not sure about newer things < 1566095504 168186 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :(Nephelem has some.. weird constraints) < 1566095578 682324 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right, I can see why a comparison of the bottom 8 bits with 0xC1 (which would be mathematically correct) might be slower on some processors < 1566095593 672515 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :I could also see it being smaller code < 1566095600 878550 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :^ check if it's smaller < 1566095616 374992 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :fitting as many instructions in 16 bytes as possible is usually a goal < 1566095618 559643 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :shift-right is probably 1 instruction, and compare 8 bit is another < 1566095643 477414 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :and fitting 0xc100000... as an immediate is going to be longer < 1566095678 413834 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you'd simply have to replace "cmp $0xc0,%rsi" (7 bytes) with "cmp $0xc0,%sil" (4 bytes) < 1566095694 92951 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :as Hooloovo0 says, the only difference is the leading zeroes on the immedite < 1566095696 240918 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*immediate < 1566095705 166035 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :there's a subtle difference here < 1566095726 367135 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :the 32-bit registers and 64-bit ones are different, if i recall right < 1566095727 660479 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :oh, it's a 32-bit compare? weird < 1566095749 40619 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :but.. < 1566095750 949023 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :hm < 1566095753 703181 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :can i see ASM < 1566095753 742981 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Hooloovo0: it's a 64-bit compare using a 32-bit immediate, x86_64 doesn't use 64-bit immediates apart from one instruction < 1566095761 105067 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :oh, ok < 1566095777 446366 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ais523: can you make a quick listing of the ASM here? < 1566095783 850095 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mov %rdx,%rsi \ shr $0x38,%rsi \ cmp \ $0xc0,%rsi < 1566095789 841201 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, I added an extra slash < 1566095799 573053 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mov %rdx,%rsi \ shr $0x38,%rsi \ cmp $0xc0,%rsi \ ja 2e < 1566095807 940438 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(then the value in %rsi is no longer used, nor are the flags) < 1566095812 942461 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :can't downgrade to a 32-bit register. < 1566095822 885305 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :moony: %esi is just the bottom half of %rsi < 1566095838 190982 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :No, they're treated different if i remember right < 1566095856 623598 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the complication you're thinking of is that if you ever assign to %esi directly, it gets automatically zero-extended into %rsi < 1566095865 310862 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ahg < 1566095867 449100 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ah < 1566095874 270063 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :alright, i'm being a derp < 1566095881 942973 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :i.e. the /top half/ of %rsi is like a register of its own with its own weird rules < 1566095908 545684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(meanwhile, assigining to %si or %sil does not clear any other part of %rsi, the rule's only for the $e* variant of registers specifically) < 1566095945 134254 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I saw a post recently about which amd64 registers aren't special-cased in some way. It's only a few of them. < 1566095945 248862 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that last bit i did /not/ know < 1566095946 608619 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :what < 1566095952 509596 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…which is why xchg %ax, %ax is a no-op, because that's a 16-bit write < 1566095963 450690 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :whose idea was this < 1566095965 72550 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :Hooloovo0: yes, welcome to x86 < 1566095975 254661 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: six of r8..r15 are not special-cased, I think < 1566095976 433232 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :it's all in the name of (misguided) backwards compatibility < 1566095984 429439 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, r9..r16 < 1566096004 349205 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I can't remember which two it is that are, it's either 10 and 11, 11 and 12, or 12 and 13 < 1566096012 171195 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, https://twitter.com/rygorous/status/1162078329706405888 < 1566096018 665510 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :man, fuck computers < 1566096030 796443 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Wait, writing to ax doesn't zero the top half of rax? < 1566096035 225753 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: right < 1566096043 925678 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :nor eax < 1566096046 709766 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is what I was missing when we had our nop discussion a while back < 1566096084 56672 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :Hooloovo0: i await the day RISC-V takes over the world with sane design < 1566096086 37150 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so 90 is a nop because it's special-cased, even though that instruction would normally decode to xchg eax, eax (this forces you to use a different encoding if you actually want the swap) < 1566096105 576833 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but 66 90 is a nop semantically, it swaps ax with itself and that doesn't have side effects < 1566096122 748980 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(although it's almost certainly special-cased anyway, that's just for performance reasons) < 1566096123 370543 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh man. < 1566096133 153959 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I feel like I came across this fact once before but I completely forgot about it. < 1566096136 158224 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What a mess. < 1566096144 388986 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I want RISC-V to take over the world < 1566096164 456969 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is why disassemblers can disassemble 66 90 to xchgw ax, ax without being incorrect < 1566096188 415331 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :yeah, risc-v is nice < 1566096197 382375 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :ACTION has designed a risc-v cpu < 1566096251 401160 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Until now I thought that anything that only wrote to the lower 32 bits automatically zeroed the upper 32 bits. < 1566096253 224483 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I want a decently priced linux capable RISC-V board < 1566096255 886159 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :then i will be happy < 1566096312 213386 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fwiw, the special-casing on r12 is almost forgivable, the issue is that some notation is needed to be able to specify not using a register; x86 sacrificed the ability to write an address that requires multiplying the stack pointer by a constant (somewhat understandably) to give the encodings it needed < 1566096338 195146 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and r12 is encoded by specifying "stack pointer, except second set of registers" and that would therefore need a special-case decode to allow you to multiply it by a constant < 1566096371 4465 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, both r12 and r13 are inheriting restrictions from rsp and rbp. < 1566096475 397265 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I came up with a new optimisation idea a while back: the idea is that when you're implementing an array of structures as parallel arrays (e.g. for alignment reasons), you take a pointer into the array with smallest elements < 1566096496 16843 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and index into the others by multiplying the /pointer/ by a constant and adding another constant with an appropriately calculated value < 1566096515 840414 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(or if the arrays don't have fixed addresses, e.g. in a re-entrant function, another register) < 1566096535 257053 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in the non-fixed-address scenario this saves one register over the obvious way of writing things and isn't any longer or slower < 1566096556 5623 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although it's really highly illegal in C, you can do it in x86 asm just fine < 1566096559 322044 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :Hooloovo0: if you think the base x86-64 stuff is insane < 1566096562 784739 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :mess with SSE < 1566096582 228199 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :AVX seems to have hit a sweet spot of performance and sanity, IMO < 1566096590 145674 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :Yea, AVX is ok < 1566096590 206446 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :then it started going back downhill from AVX2 onwards < 1566096599 840388 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :AVX-512 ;-; < 1566096607 122374 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What was wrong with AVX2? < 1566096613 334390 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I've come to the decision to target AVX1 as my baseline instruction set < 1566096623 500549 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It gave a lot of integer instructions that were missing in AVX1. < 1566096625 514244 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: nothing massively wrong, it just has some jarring inconsistencies and missing features < 1566096648 297701 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :also the useless instructions < 1566096652 215937 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that only have one use < 1566096656 450466 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :and are junk for anything else < 1566096660 540417 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :A while ago I wanted to write vectorized code and I couldn't use AVX. < 1566096667 24710 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. there are no instructions to operate on 256-bit values as a whole, only pairs of 128-bit values < 1566096677 48504 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can't shift the top half of a ymm value into the bottom half < 1566096701 700697 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is weird, because you can shift the top half and bottom half of a ymm value separately into the top and bottom halves respectively of a second ymm value < 1566096702 454869 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :RISC-V's vector extension is looking really good < 1566096707 477561 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :you seen it, ais523? < 1566096713 371981 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :no < 1566096733 183168 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :https://github.com/riscv/riscv-v-spec < 1566096779 871622 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :it's great < 1566096787 818732 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :completely vector register width agnostixc < 1566096790 152389 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :*agnostic < 1566096799 952889 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :so that old code can utilize larger register sizes easily < 1566096902 41803 :Hooloovo0!Hooloovoo@sorunome.de PRIVMSG #esoteric :should x86 be considered an esolang? < 1566096917 425344 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :prolly < 1566096923 821674 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :a esolang that everyone uses < 1566096980 506148 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Much less than C++, I think. < 1566097569 932576 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :What I would want to have is the bitwise operations that MMIX has. There is a bit operation extension for RISC-V, but I think the bit operations of MMIX is better. < 1566097587 277073 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(At least, for a 64-bit system, it is better. Perhaps for a 32-bit system maybe it isn't better.) < 1566097594 14506 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :zzo38: are MAK and EXT (MAKe and EXTract) in that list? < 1566097603 224127 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :they're both bitfield opts < 1566097605 385203 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :*ops < 1566097618 199471 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :really powerful, enough that they can replace shiftleft/shiftright instructions < 1566097656 280247 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :What are MAK and EXT doing? < 1566097687 669263 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(I also like the Muxcomp operation, described in esolang wiki) < 1566097689 629657 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :ACTION pulls up MC88100 desc of them < 1566097810 303736 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :zzo38: http://bitsavers.trailing-edge.com/components/motorola/88000/MC88100_RISC_Microprocessor_Users_Manual_2ed_1990.pdf pages 3-44, 3-45, 3-46, 3-47, 3-70, and 3-71, < 1566097826 550050 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :it has diagrams describing operation, alongside text < 1566097887 134156 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Do you have the order number of the page? < 1566097915 936956 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :one sec < 1566097954 12915 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :MAK is on 125.. < 1566097985 882006 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :EXT on 99. < 1566098034 908189 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :that good, zzo38? < 1566098065 198915 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :I own the physical manual, forgot that the PDF is annoying to navigate < 1566098110 193988 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, that is good < 1566098124 746229 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(I didn't read all of it yet though) < 1566098459 596805 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :That MAK and EXT is good. (MMIX doesn't have it, but does have MOR and MXOR and SADD (MOR is very useful), and Muxcomp is even more general to do) < 1566098505 624407 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(A problem with Muxcomp though, is that it requires a lot of operands.) < 1566098618 77180 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Muxcomp is: Form a 5-bit number from the low bits of each of the first five operands to select which bit of the last operand to copy to the low bit of the result, and then the same for the next bit position, and so on. < 1566098689 930194 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(Or six bits for 64-bit registers) < 1566098765 433472 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: doesn't that effectively implement an arbitrary five-input bitwise operator? < 1566098771 558598 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :with the last operand specifying the truth table? < 1566098780 633756 :kolontaev!~kolontaev@slow.wreckage.volia.net PRIVMSG #esoteric :what do you use MOR for? if it's useful... < 1566098837 839284 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :ais523: I suppose so, yes. (You can also perform a shift or rotate of the last operand by setting the other operands properly) < 1566098840 284072 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :MAK and EXT have the advantage of practicality < 1566098863 275421 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :kolontaev: One use is endian switch (including PDP-endian). < 1566098872 988681 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :But there are some other uses, too. < 1566098881 166555 :kolontaev!~kolontaev@slow.wreckage.volia.net PRIVMSG #esoteric :zzo38: aha < 1566098921 282419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a while back in here we were discussing how Intel had added INTERCAL's select operator ~ to the x86 instruction set < 1566098974 33507 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the paper discussing it mentioned an instruction that's effectively a bitwise keysort; you stable-sort the bits of one operand using the bits of the other operand as keys < 1566099004 653334 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that hasn't been implemented but it seems like it could be useful < 1566099012 229564 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(a select is basically a bitwise-keysort followed by an AND) < 1566099019 105922 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, preceded by an AND < 1566099276 568827 :ARCUN!6cf5fc98@108-245-252-152.lightspeed.miamfl.sbcglobal.net JOIN :#esoteric < 1566099355 322467 :ARCUN!6cf5fc98@108-245-252-152.lightspeed.miamfl.sbcglobal.net PRIVMSG #esoteric :cpressey: Do you know where I could get an actual Commodore 64? I need one for a project. < 1566099363 837094 :ARCUN!6cf5fc98@108-245-252-152.lightspeed.miamfl.sbcglobal.net QUIT :Remote host closed the connection < 1566099445 108611 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :uh < 1566099446 585115 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :huh < 1566099561 806395 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :ais523: Yes, I think it can be useful > 1566099746 404883 PRIVMSG #esoteric :14[[07Commercial14]]4 10 02https://esolangs.org/w/index.php?diff=65539&oldid=65535 5* 03Dtuser1337 5* (+8) 10Formatting codebase. < 1566099824 74776 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :MMIX doesn't have a "count trailing zero" instruction, but it can easily be done with two instructions (the SADD instruction is popcount(x AND NOT y)) > 1566099826 294520 PRIVMSG #esoteric :14[[07Commercial14]]4 10 02https://esolangs.org/w/index.php?diff=65540&oldid=65539 5* 03Dtuser1337 5* (-6) 10continue formatting codebase and move category to bottom > 1566099947 644094 PRIVMSG #esoteric :14[[07Commercial14]]4 10 02https://esolangs.org/w/index.php?diff=65541&oldid=65540 5* 03Dtuser1337 5* (-52) 10/* Implementations */ < 1566099980 92554 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: is that (x-1) sadd x? > 1566100005 507346 PRIVMSG #esoteric :14[[07ORK14]]4 10 02https://esolangs.org/w/index.php?diff=65542&oldid=53698 5* 03Dtuser1337 5* (+13) 10/* External resources */ < 1566100055 710065 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes. > 1566104060 93969 PRIVMSG #esoteric :14[[07Camouflage14]]4 10 02https://esolangs.org/w/index.php?diff=65543&oldid=30836 5* 03Dtuser1337 5* (+24) 10 > 1566104089 564523 PRIVMSG #esoteric :14[[07ZOMBIE14]]4 10 02https://esolangs.org/w/index.php?diff=65544&oldid=53713 5* 03Dtuser1337 5* (+20) 10 < 1566104916 567915 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1566110106 906161 :nfd9001!~nfd9001@2601:602:8500:2443:395e:78ef:ab2:ff1 JOIN :#esoteric < 1566112741 253346 :rain1!~My_user_n@unaffiliated/rain1 JOIN :#esoteric < 1566116652 167257 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 245 seconds < 1566116848 445467 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1566117127 600690 :AnotherTest!~turingcom@ptr-82l26zcdc6imrwoapg3.18120a2.ip6.access.telenet.be JOIN :#esoteric < 1566118371 909986 :nfd9001!~nfd9001@2601:602:8500:2443:395e:78ef:ab2:ff1 QUIT :Ping timeout: 264 seconds < 1566118508 751445 :nfd9001!~nfd9001@2601:602:8500:2443:395e:78ef:ab2:ff1 JOIN :#esoteric < 1566118921 204014 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu JOIN :#esoteric < 1566119141 586380 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: "~b has to be a positive number in the 0..30 range" => I think you mean in the 0..0x3E inclusive range < 1566119263 74488 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :"should I write it as 1 + (ptrdiff_t)(signed char)b in the original source" => use an ifdef, with the original version inactive and the optimized version active, write a comment that it's an optimization, and then check that the optimized version is compiled the way you want < 1566119283 955030 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that said, isn't it possible that this is a case where the optimization doesn't matter? > 1566119458 40842 PRIVMSG #esoteric :14[[07Edition14]]4 N10 02https://esolangs.org/w/index.php?oldid=65545 5* 03A 5* (+874) 10Created page with "Edition language Double speak example I"$R. C"F"0@i1@i Explanation I Take input "$ Copy the input's length to clipboard R. Read the current file's content into the..." < 1566119472 3023 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :"the in-memory representation of a parse tree" => that wasn't my guess < 1566119538 330870 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru JOIN :#esoteric < 1566119621 597365 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :"having a separate call stack and data stack is a much better idea" => is it still, now that CPUs cache the top of the call stack as an optimization? < 1566119801 708882 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: moving objects around but without a gc, "at first I thought "surely that isn't necessary", but then came up with some pathological programs where it is" => in the kernel, trying to free up pages when it has lots of individually allocated small structures fragmented around memory < 1566119846 696178 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :kernel people are actually working on that, and yes, the disadvantages are terrifying, although I think they're doing it more memory conservingly than doubly linking every individual pointer < 1566119988 975471 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :hi. Nice it’s calm and wise here as usual :) < 1566120050 458466 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :(I was without IRC for two weeks and in some reason I’m still unpacking) < 1566120160 464451 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :"comparison with 0xC100000000000000" => that's because you can't have immediates larger than 32 bits, so it has to be two instructions anyway. that it's a shift of the input is still a bit surprising to me, but apparently that's how you can get it in just two instructions, rather than just three as in loading the constant in two instructions. < 1566120217 793073 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :may also depend on the context < 1566120263 322178 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :hm I played a game called Weave where you place tiles on a hexagonal grid, each tile having two points marked on each side and connecting these points by curved segments in some fashion as to make various intertwined paths when many tiles are placed together. Now I suddenly wonder if something can be esonalged from there < 1566120326 164197 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :"you'd simply have to replace "cmp $0xc0,%rsi" (7 bytes) with "cmp $0xc0,%sil" (4 bytes)" => why? isn't there an encoding of "cmp $0xc0,%rsi" that has a 1-byte immediate? < 1566120357 249119 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :turns and “knottiness” of paths could be used for semantics, and there are only so many tiles available to make the composition not so trivial < 1566120420 32598 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :also I think I have already seen those tiles somewhere even before that game, but don’t remember where < 1566120486 248664 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :and it could be downplayed to square tiles if necessary. If anybody would be interested, I’ll link to that game in G.Play and/or draw examples of tiles < 1566120494 410464 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :how would gcc even get the assembler to emit the encoding with the 4-byte immediate? < 1566120694 297947 :int-e!~noone@int-e.eu PRIVMSG #esoteric :b_jonas: 0xc0 is too big for a one-byte immediate < 1566120712 370678 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(because they are sign-extended) < 1566120749 778199 :int-e!~noone@int-e.eu PRIVMSG #esoteric :and I thought picking immediate sizes was the assembler's job, not gcc's. < 1566120796 201664 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh, but choosing operand sizes isn't... that's the point. < 1566120832 861633 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: ah ok < 1566120840 419186 :int-e!~noone@int-e.eu PRIVMSG #esoteric :And intel only offers the choice between one byte immediates and full byte immediates. < 1566120855 826655 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I meant s/full byte/full size/ < 1566120863 503367 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: gcc would know what size the instruction has, in fact the whole part where it outputs assembly rather than the object code directly is mostly for human-debuggability I think < 1566120908 848217 :int-e!~noone@int-e.eu PRIVMSG #esoteric :I'm not sure that is the case. gcc probably has a good idea how big instructions will be, of course. < 1566120924 491468 :int-e!~noone@int-e.eu PRIVMSG #esoteric :But I would hope it doesn't rely on always being correct. < 1566121560 361264 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: it certainly dones't have to know for rare slow instructions, because it can handle unknown instructions in asm statements, but for when it generates fast code, it probably knows the instruction size for optimization < 1566121574 119397 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :(for x86_64) < 1566121600 834573 :int-e!~noone@int-e.eu PRIVMSG #esoteric :b_jonas: Sorry, I'll take that as speculation unless you have proof. < 1566121614 288946 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :unrelated, but http://www.wyrdplay.org/AlanBeale/CAAPR-ref.html is a small English pronunciation dictionary by the author of 12dicts that seems to be well compiled < 1566121656 755793 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(For example, a key purpose of things like .align is that the compiler can align code without knowing exactly how big the individual instructions are.) < 1566121856 593336 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: again, gcc generally doesn't know how long the emitted instructions from an asm statement are, which is documented in the gcc docs because it also says that gcc assumes an upper bound and what sneaky things you shouldn't do in the asm statement to violate that < 1566121876 313818 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: and gcc probably can't tell the length of some jump instructions in the first pass < 1566121900 442860 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :that said, some of the assembly syntax is probably for humans, not for compilers < 1566121916 34266 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :like, do you think the compiler needs both decimal and hex integer syntax? < 1566121952 986075 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :the .align too can be useful to make the assembly output more readable, even in the case when the compiler does happen to know how many bytes it emits < 1566121973 568926 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :plus .align 16 is shorter than the assembly mnemonic of a 9-byte nop instruction < 1566122131 49268 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :or looks nicer, rather < 1566122133 378103 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :shorter doesn't matter < 1566122174 384559 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1566123054 737806 :botnick!~botuser@bl14-199-237.dsl.telepac.pt JOIN :#esoteric < 1566123084 673527 :botnick!~botuser@bl14-199-237.dsl.telepac.pt QUIT :Read error: Connection reset by peer < 1566126717 445813 :FreeFull!~freefull@defocus/sausage-lover QUIT : < 1566126757 520011 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`card-by-name Hecatomb < 1566126758 557255 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :Hecatomb \ 1BB \ Enchantment \ When Hecatomb enters the battlefield, sacrifice Hecatomb unless you sacrifice four creatures. \ Tap an untapped Swamp you control: Hecatomb deals 1 damage to any target. \ IA-R, 5E-R, 6E-R, MED-R < 1566126778 385088 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :^ It seems a bit underwhelming that they use the word "hecatomb" for the sacrifice of a mere four creatures < 1566126819 313794 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :`card-by-name Epic Struggle < 1566126819 976972 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :Epic Struggle \ 2GG \ Enchantment \ At the beginning of your upkeep, if you control twenty or more creatures, you win the game. \ JUD-R < 1566127063 189551 :livesex_0699!~livesex_0@91.203.193.59 JOIN :#esoteric < 1566127066 722948 :livesex_0699!~livesex_0@91.203.193.59 PART :#esoteric < 1566127599 159962 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :(The helix pineaple requires you to pay mana only, not sacrifice creatures.) < 1566130671 222236 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 JOIN :#esoteric < 1566130675 661677 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :hi < 1566130727 51695 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :idea: programming language only usable from last thursday to next thursday < 1566131253 85306 :dog_star_!sid310875@gateway/web/irccloud.com/x-sqansztzearqalna NICK :dog_star < 1566131352 198215 :dog_star!sid310875@gateway/web/irccloud.com/x-sqansztzearqalna QUIT : < 1566131373 184927 :dog_star!sid310875@gateway/web/irccloud.com/x-qqwpcmuzaaorupje JOIN :#esoteric < 1566131407 535360 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :hi doh < 1566133436 627241 :xkapastel!uid17782@gateway/web/irccloud.com/x-cncoqohytlhpkouy JOIN :#esoteric < 1566133841 66179 :tromp_!~tromp@2a02:a210:1585:3200:553d:686a:de85:c785 QUIT :Remote host closed the connection > 1566135384 84977 PRIVMSG #esoteric :14[[07~English14]]4 10 02https://esolangs.org/w/index.php?diff=65546&oldid=37171 5* 03Dtuser1337 5* (+24) 10this is a high level language due to how it looked like. > 1566135417 119205 PRIVMSG #esoteric :14[[07Commercial14]]4 10 02https://esolangs.org/w/index.php?diff=65547&oldid=65541 5* 03Dtuser1337 5* (+24) 10 > 1566135450 510962 PRIVMSG #esoteric :14[[07Drive-In Window14]]4 10 02https://esolangs.org/w/index.php?diff=65548&oldid=65536 5* 03Dtuser1337 5* (+23) 10 < 1566135779 220420 :arseniiv_!~arseniiv@89.189.147.93.dynamic.ufanet.ru JOIN :#esoteric < 1566135779 357333 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru QUIT :Read error: Connection reset by peer < 1566136083 256950 :Frater_EST!~adrianbib@wsip-68-15-198-210.ok.ok.cox.net JOIN :#esoteric < 1566136186 83716 :Frater_EST!~adrianbib@wsip-68-15-198-210.ok.ok.cox.net PART :#esoteric < 1566136254 912092 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 JOIN :#esoteric < 1566136457 244211 :MDude!AdiIRC@c-174-55-101-236.hsd1.pa.comcast.net QUIT :Quit: Going offline, see ya! (www.adiirc.com) < 1566136551 902981 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 QUIT :Ping timeout: 264 seconds < 1566137061 969465 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 JOIN :#esoteric < 1566142450 573096 :Sgeo__!~Sgeo@ool-18b98c99.dyn.optonline.net JOIN :#esoteric < 1566142627 912325 :Sgeo_!~Sgeo@ool-18b98c99.dyn.optonline.net QUIT :Ping timeout: 248 seconds < 1566144616 142274 :xkapastel!uid17782@gateway/web/irccloud.com/x-cncoqohytlhpkouy QUIT :Quit: Connection closed for inactivity < 1566147072 303844 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 QUIT :Remote host closed the connection < 1566147184 586899 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Is thre a metric-only font format in PostScript? < 1566147717 916652 :tromp!~tromp@ip-213-127-58-74.ip.prioritytelecom.net JOIN :#esoteric < 1566148226 996942 :xkapastel!uid17782@gateway/web/irccloud.com/x-iuslimwkhyenvlrr JOIN :#esoteric < 1566148437 91414 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :hi zzo < 1566148465 686231 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Hello < 1566148554 289515 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :what is your favorite eso you've made < 1566148560 268814 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :your crowning achievement in a sense < 1566148880 861055 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I don't know. < 1566148898 842983 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :(I think that I do not make a "crowning achievement") < 1566148907 583660 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :zzo38: you mean like for overlaying text on a scanned image of a text? I think you could use a vector font where all the glyphs are blank < 1566148942 20347 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :well then zzo < 1566148942 375728 :Sgeo!~Sgeo@ool-18b98c99.dyn.optonline.net JOIN :#esoteric < 1566148999 193422 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :are you david madore , b < 1566149004 436506 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :b_jonas: Actually I mean for use with an output driver that will provide its own glyphs or convert to some other format that will then be processed by something which provides its own glyphs, although it would also work to overlay text on a scanned image of text too < 1566149012 762875 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :andrewtheircer: No, I am Aaron Black. < 1566149023 294395 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :well then < 1566149040 532190 :Sgeo__!~Sgeo@ool-18b98c99.dyn.optonline.net QUIT :Ping timeout: 272 seconds < 1566149042 211986 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :does everyone know you are aaron black < 1566149078 23634 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :if not < 1566149080 734112 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :this is big revel < 1566149107 763219 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I don't know, but I think it doesn't really matter so much. I am just known as "zzo38", and will not confuse with other people also named Aaron Black, I think. < 1566149121 754026 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :zzo38: ok. I'd think a font with blank or dummy vector images would work for that too < 1566149139 870928 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :nice stuff aaron < 1566149154 456742 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :also:i was asking b_jonas if they were david madore < 1566149200 635969 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :andrewtheircer: of course not < 1566149204 117384 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :b_jonas: Yes, that would work, I suppose < 1566149208 611345 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :d'oof < 1566149295 281519 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :zzo38: but maybe otf already has a way to indicate that a font has metrics only. few people know how font formats actually work. maybe oren knows. < 1566149678 658148 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :it's a low voodoo about font formats < 1566149765 955009 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :it's not surprising that nobody understand them: there's a lot of historical baggage of evolving technology, and a lot of useful optimization < 1566150246 744226 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 QUIT :Remote host closed the connection < 1566150385 202306 :tromp!~tromp@ip-213-127-58-74.ip.prioritytelecom.net QUIT :Remote host closed the connection < 1566151135 614198 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 JOIN :#esoteric < 1566151749 182874 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 QUIT :Remote host closed the connection < 1566152232 210905 :arseniiv_!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :I am also not David Madore < 1566152236 47665 :arseniiv_!~arseniiv@89.189.147.93.dynamic.ufanet.ru NICK :arseniiv < 1566153580 460439 :tromp!~tromp@ip-213-127-58-74.ip.prioritytelecom.net JOIN :#esoteric < 1566153845 412784 :tromp!~tromp@ip-213-127-58-74.ip.prioritytelecom.net QUIT :Ping timeout: 244 seconds > 1566154445 10218 PRIVMSG #esoteric :14[[07PureStack14]]4 10 02https://esolangs.org/w/index.php?diff=65549&oldid=41588 5* 03Dtuser1337 5* (+27) 10 > 1566154511 363890 PRIVMSG #esoteric :14[[07Super Stack!14]]4 10 02https://esolangs.org/w/index.php?diff=65550&oldid=37526 5* 03Dtuser1337 5* (+24) 10 > 1566154544 539946 PRIVMSG #esoteric :14[[07Super Stack!14]]4 10 02https://esolangs.org/w/index.php?diff=65551&oldid=65550 5* 03Dtuser1337 5* (-24) 10 > 1566154668 320760 PRIVMSG #esoteric :14[[07Super Stack!14]]4 10 02https://esolangs.org/w/index.php?diff=65552&oldid=65551 5* 03Dtuser1337 5* (+23) 10 < 1566154756 66010 :adu!~ajr@pool-173-73-86-191.washdc.fios.verizon.net JOIN :#esoteric < 1566154888 48203 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I think the font formats with METAFONT is good. > 1566155644 45466 PRIVMSG #esoteric :14[[07Emoji14]]4 10 02https://esolangs.org/w/index.php?diff=65553&oldid=46750 5* 03Dtuser1337 5* (+104) 10Adding some categories. < 1566155953 377917 :Sgeo!~Sgeo@ool-18b98c99.dyn.optonline.net QUIT :Ping timeout: 244 seconds > 1566156070 530543 PRIVMSG #esoteric :14[[07Emoji14]]4 10 02https://esolangs.org/w/index.php?diff=65554&oldid=65553 5* 03Dtuser1337 5* (+24) 10Added output only category due to potential no input. < 1566156162 567421 :Sgeo!~Sgeo@ool-18b98c99.dyn.optonline.net JOIN :#esoteric < 1566156399 990810 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 JOIN :#esoteric > 1566156474 536053 PRIVMSG #esoteric :14[[07Hello world program in esoteric languages14]]4 10 02https://esolangs.org/w/index.php?diff=65555&oldid=65405 5* 03Dtuser1337 5* (+39) 10 > 1566156751 126828 PRIVMSG #esoteric :14[[07Hello world program in esoteric languages14]]4 10 02https://esolangs.org/w/index.php?diff=65556&oldid=65555 5* 03Dtuser1337 5* (+746) 10/* Emoji */ > 1566157081 543743 PRIVMSG #esoteric :14[[07Hello world program in esoteric languages14]]4 10 02https://esolangs.org/w/index.php?diff=65557&oldid=65556 5* 03Dtuser1337 5* (+91) 10/* suicide */ < 1566157165 207075 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 QUIT :Remote host closed the connection > 1566157231 163785 PRIVMSG #esoteric :14[[07Hello world program in esoteric languages14]]4 10 02https://esolangs.org/w/index.php?diff=65558&oldid=65557 5* 03Dtuser1337 5* (+152) 10/* MATL */ < 1566157236 853089 :adu!~ajr@pool-173-73-86-191.washdc.fios.verizon.net QUIT :Quit: adu < 1566157269 551088 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1566158059 547498 :sombrero!b5cb09ce@181.203.9.206 JOIN :#esoteric < 1566158135 896238 :sombrero!b5cb09ce@181.203.9.206 PRIVMSG #esoteric ::0 the style has changed < 1566158165 537714 :int-e!~noone@int-e.eu PRIVMSG #esoteric :style? < 1566158194 618290 :int-e!~noone@int-e.eu PRIVMSG #esoteric :Oh the webchat I guess. IRC is a pure text-based protocol, it has no style. < 1566158208 910305 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 JOIN :#esoteric < 1566158210 49136 :sombrero!b5cb09ce@181.203.9.206 PRIVMSG #esoteric :yep the frontend < 1566158258 471550 :Sgeo_!~Sgeo@ool-18b98c99.dyn.optonline.net JOIN :#esoteric < 1566158321 98241 :int-e!~noone@int-e.eu PRIVMSG #esoteric :sombrero: you're the only user of the webchat here, it seems. < 1566158356 73888 :sombrero!b5cb09ce@181.203.9.206 PRIVMSG #esoteric :??? < 1566158452 128256 :int-e!~noone@int-e.eu PRIVMSG #esoteric :(But I'm not sure, some people are cloaked which hides this information.) In any case, there are many IRC clients. The Freenode webchat frontend is just one of them. < 1566158464 535420 :Sgeo!~Sgeo@ool-18b98c99.dyn.optonline.net QUIT :Ping timeout: 272 seconds < 1566158488 341776 :int-e!~noone@int-e.eu PRIVMSG #esoteric :https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients <-- many < 1566158511 223522 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, and I use one I wrote by myself. Others may also use programs not mentioned on Wikipedia, too < 1566158817 179002 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 QUIT :Remote host closed the connection < 1566158927 804846 :sombrero!b5cb09ce@181.203.9.206 PRIVMSG #esoteric ::v anyway, i would be very happy if take a look to a compilation of drawing http://vixra.org/abs/1907.0332 and give your criticss, It would be pretty nice if this inspires some good ideas to make new stuff ;) < 1566159026 384672 :sombrero!b5cb09ce@181.203.9.206 PRIVMSG #esoteric :(esoteric answers and comment are well accepted ;P) < 1566159443 770849 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :int-e: on freenode, the webchat cloak overrides the other cloaks, so you can't hide it that way < 1566159498 524528 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :hmm < 1566159522 431770 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :sorry, apparently that doesn't apply to kiwi (oh I hate that client by the way), only some other webchats < 1566159533 454798 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :because sombrero's hostname isn't a cloak < 1566159742 617250 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 JOIN :#esoteric < 1566159804 244013 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1566159952 469421 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 244 seconds < 1566159953 50841 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life < 1566160421 679941 :sombrero!b5cb09ce@181.203.9.206 QUIT :Remote host closed the connection < 1566160834 899133 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric < 1566163315 529421 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Priests of Sun {1W} Creature - Human Cleric (1/1) ;; {1W}: Target creature gets +0/+1 until end of turn. ;; {T}: Tap target blocking creature. That creature gets +1/+2 until end of turn. < 1566163342 190388 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Priests of Worm {1B} Creature - Human Cleric (1/1) ;; {(B/P)}: ~ gains first strike and haste until end of turn. ;; {T}, Sacrifice a non-artifact creature: Add {BB}. < 1566164353 601329 :AnotherTest!~turingcom@ptr-82l26zcdc6imrwoapg3.18120a2.ip6.access.telenet.be QUIT :Ping timeout: 250 seconds < 1566164365 272583 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover QUIT :Quit: Leaving < 1566165727 937443 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 JOIN :#esoteric < 1566165977 278760 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator QUIT :Ping timeout: 245 seconds < 1566165988 631942 :Bowserinator_!Bowserinat@hellomouse/dev/Bowserinator JOIN :#esoteric < 1566167321 343006 :Sgeo!~Sgeo@ool-18b98c99.dyn.optonline.net JOIN :#esoteric < 1566167392 383855 :Sgeo_!~Sgeo@ool-18b98c99.dyn.optonline.net QUIT :Ping timeout: 244 seconds < 1566167767 304349 :Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net JOIN :#esoteric < 1566167953 303674 :Sgeo!~Sgeo@ool-18b98c99.dyn.optonline.net QUIT :Ping timeout: 245 seconds < 1566168431 816581 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Do you like this cards? < 1566168445 525839 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :who is cards < 1566168506 510288 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Magic: the Gathering cards < 1566168527 477583 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 PRIVMSG #esoteric :og < 1566168530 680962 :andrewtheircer!4d2ecf02@gateway/web/cgi-irc/kiwiirc.com/ip.77.46.207.2 QUIT :Remote host closed the connection < 1566168604 249327 :xkapastel!uid17782@gateway/web/irccloud.com/x-iuslimwkhyenvlrr QUIT :Quit: Connection closed for inactivity < 1566170283 906396 :nfd9001!~nfd9001@2601:602:8500:2443:395e:78ef:ab2:ff1 QUIT :Ping timeout: 264 seconds < 1566170314 557497 :nfd9001!~nfd9001@2601:602:8500:2443:395e:78ef:ab2:ff1 JOIN :#esoteric < 1566171544 533692 :tromp_!~tromp@ip-213-127-58-74.ip.prioritytelecom.net JOIN :#esoteric < 1566171659 619145 :tromp!~tromp@2a02:a210:1585:3200:1172:5930:431e:a597 QUIT :Ping timeout: 250 seconds < 1566171871 954221 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru PRIVMSG #esoteric :@tell sombrero what are polysigns mentioned in the abstract of the thing you linked? < 1566171872 319723 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1566171915 528192 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1566171923 637011 :FreeFull!~freefull@defocus/sausage-lover QUIT : < 1566172008 631031 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: the kernel uses intrusive lists a lot so it may be that a large proportion of the pointers are already doubly linked, that makes doubly-linking all of them a little less insane < 1566172072 721747 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : "you'd simply have to replace "cmp $0xc0,%rsi" (7 bytes) with "cmp $0xc0,%sil" (4 bytes)" => why? isn't there an encoding of "cmp $0xc0,%rsi" that has a 1-byte immediate? ← no, there isn't, 1-byte immediates only exist as offsets of memory addresses (which is why lea is useful) and on byte instructions < 1566172089 822112 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :at least, on instructions like cmp that use a fairly normal encoding < 1566172153 270561 :arseniiv!~arseniiv@89.189.147.93.dynamic.ufanet.ru QUIT :Ping timeout: 245 seconds < 1566172162 660010 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: they do exist on ordinary word instructions like cmp, but int-e says that they're signed so it won't work here -- I haven't checked that, it's really hard to figure out from intel manuals which things are sign extended and which ones are zero extended < 1566172203 768801 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :incidentally, it crosses my mind that you could go down to three bytes by using bl/cl/dl rather than sil, or even two bytes if al were available < 1566172218 768208 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: ah, OK < 1566172221 860857 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think it's often the case that instead of pointers you want to use some alternative like indices, if you have a lot of them. That already allows for some kinds of relocation. < 1566172228 83709 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's a simple rule for this, one-byte immediates in x86 are /always/ signed < 1566172260 496791 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :they also exist for the shortcut %eax arithmetic instructions, but annoyingly not for mov, despite that a word mov with one-byte immediate would be often very convenient < 1566172262 501386 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so the only time they're treated as unsigned is if the instruction treats its operand as unsigned /and/ it only has a 1-byte operand, in which case it gets sign-extended to its own length and then treated as unsigned < 1566172300 729429 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ais523: including one-byte offsets for memory operands? < 1566172307 994989 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: yes < 1566172312 57332 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ok < 1566172320 499333 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is why the x86_64 ABI has a redzone, it's to make use of the positive offsets on SP < 1566172337 940277 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :ok < 1566172374 956377 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, a signed immediate /would/ work here, you'd simply need to do a signed shift rather than an unsigned shift < 1566172400 548152 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :hmm < 1566172419 427380 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or, hmm, maybe not < 1566172435 735504 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because with the signed interpretation, you're checking for values between 0 and a negative constant < 1566172439 495004 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which isn't all at one end of the range < 1566172450 707135 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ugh < 1566172692 304381 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :I just realized that it's funny how you first say that x86 doesn't have one-byte immediates for word instructions, then said that they're all signed < 1566172733 459311 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's the way that memory works, I think < 1566172750 780194 :moony!moony@hellomouse/dev/moony PRIVMSG #esoteric :Insert complaint about x86's insanity here. < 1566172775 675383 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :don't lawyers have a phrase "in the alternative" for describing situations like this? < 1566172781 457207 :b_jonas!~x@catv-176-63-25-8.catv.broadband.hu PRIVMSG #esoteric :but yes, it is signed