< 1611361003 579530 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1611361430 491531 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :" does the `volatile` keyword do anything useful nowadays?" => probably, but you rarely want it, and you definitely don't want volatile for synchronization between threads or processes (or cpu threads at the lower level), you want C99 atomics or C++ atomics and all the higher level stuff for that, and it's not quite clear to me how you're supposed to do communication with a signal handler and < 1611361436 749548 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :whether volatiles are still relevant for that. < 1611361523 582356 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :yes, atomics are defined more explicitly, and it's important that atomics can do two things for one goal: they can forbid the compiler from reordering memory access, and they can forbid the CPU from reordering memory access (on modern cpus that do that) < 1611361599 215977 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :but what volatile is supposed to mean I have no clear idea < 1611361689 805227 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :I think at minimum it ensures the number of reads/writes at the assembly level is the same as at the source level < 1611361708 303389 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :disabling optimizations such as hoisting a load out of a loop < 1611361710 142809 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :which is important if reads/writes have side effects < 1611361755 273345 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :as ais523 pointed out, this means little to nothing on a modern out of order, cached, possibly SMP system < 1611361762 979618 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :but it's still very meaninful for microcontrollers < 1611361793 253185 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :"in which case, you use volatile sig_atomic_t to specify that the flag should be written in a single machine instruction" => perhaps, but it's not clear if this actually still works in modern compilers. I mean, it made sense in old barely-optimizing compilers to just have a type synonym for a type that's as wide as the typical write instructions, so you don't try to use a 32-bit int on a cpu where all < 1611361799 259997 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :32-bit access will be implemented as two 16-bit accesses. but these days, if you want to guarantee that a value is written as a whole, that's what https://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts and https://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free is for. < 1611361810 308454 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :or memory mapped IO even on full modern systems (which would be in a special region designated as uncached) < 1611361896 132292 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :did I tell y'all I got a FPGA board? https://www.sparkfun.com/products/16526 < 1611361904 716474 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :and it's supported by an open source toolchain < 1611361945 349685 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :and nMigen, which is a Python EHDL (is that a reasonable contraction of EDSL HDL?) < 1611361966 893361 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :so far i only did some simple demos with it < 1611362001 140700 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :got distracted by other things... carpentry and mushroom and plant growing projects and life stuff < 1611362005 302596 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :but i will go back to it soon < 1611362056 636953 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: if all you do in the signal handler is to set a flag, then I think relaxed atomics are fine. that means the write to that flag can be ordered in an unexpected way, but you do this for asynchronious signals, which can be delayed anyway. there's a way to force the kernel to deliver the signal handler NOW (as in before the next statement is executed)with sigsuspend, but if you do that, you won't < 1611362062 652564 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :have a signal handler that just sets a flag. < 1611362100 169993 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :if you want to do more than set a flag or _exit in your signal handler, then it's very likely that relaxed atomics aren't enough. < 1611362119 408449 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :maybe i will implement the RP2040 PIO architecture in nMigen < 1611362150 594080 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :as far as I understand, the good usecase for relaxed atomics is global counters that you very rarely increment, so you don't want to set up per-thread counters, but you want an exact total in them even in the rare and slow case when two threads increment it at the same time. < 1611362394 848963 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: re AVX1, it hasn't been around for long enough, there are still cpus without AVX in use, but your point still stands because all x86_64 cpus have SSE2 (even though the Intel manual is careful to specify everything as if that need not be true), so there's no reason to use anything older than SSE2 for floating point. > 1611362484 854585 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80187&oldid=80186 5* 03Digital Hunter 5* (+18) 10Undo revision 80186 by [[Special:Contributions/Digital Hunter|Digital Hunter]] ([[User talk:Digital Hunter|talk]]) < 1611362506 327933 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't think what you're saying is true. if you're in a code with heavy memory access, then accessing data that crosses a cache line boundary (every 16 bytes) can slow your code down. it's not just page boundaries. < 1611362535 287419 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :this applies if you're doing a lot of access to memory that's already cached, not if you're accessing main memory once that the cache can never reuse. < 1611362568 517255 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :but there are lots of pieces of code that want to do this, accessing memory already in the L1 cache multiple times. > 1611363152 153149 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80188&oldid=80187 5* 03Digital Hunter 5* (+42) 10/* Commands and keywords */ > 1611363864 710732 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80189&oldid=80188 5* 03Digital Hunter 5* (+408) 10/* Reverse cat */ Added the non-terminating example I was hoping to create. Yippee < 1611364538 596629 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru QUIT :Ping timeout: 246 seconds < 1611365073 243878 :rain1!~My_user_n@unaffiliated/rain1 QUIT :Quit: WeeChat 3.0 > 1611365094 46281 PRIVMSG #esoteric :14[[07User talk:Bo Tie14]]4 N10 02https://esolangs.org/w/index.php?oldid=80190 5* 03JonoCode9374 5* (+193) 10Created page with "I think your userpage is epic. ~~~~" > 1611365910 346494 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80191&oldid=80189 5* 03Digital Hunter 5* (+120) 10/* Commands and keywords */ > 1611366027 978194 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80192&oldid=80191 5* 03Digital Hunter 5* (+51) 10/* Commands and keywords */ > 1611366552 233567 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80193&oldid=80192 5* 03Digital Hunter 5* (+130) 10/* Numbers */ < 1611366710 558040 :imode!~imode@unaffiliated/imode JOIN :#esoteric < 1611366725 337119 :imode!~imode@unaffiliated/imode QUIT :Client Quit < 1611366744 84999 :imode!~imode@unaffiliated/imode JOIN :#esoteric > 1611368904 585363 PRIVMSG #esoteric :14[[07Rubic14]]4 10 02https://esolangs.org/w/index.php?diff=80194&oldid=75604 5* 03Digital Hunter 5* (+108) 10/* Example programs */ < 1611370410 468525 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Quit: WeeChat 2.3 > 1611370735 316217 PRIVMSG #esoteric :14[[07Trivial14]]4 N10 02https://esolangs.org/w/index.php?oldid=80195 5* 03Hakerh400 5* (+14709) 10+[[Trivial]] > 1611370778 394614 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=80196&oldid=80149 5* 03Hakerh400 5* (+14) 10+[[Trivial]] > 1611370799 432988 PRIVMSG #esoteric :14[[07User:Hakerh40014]]4 10 02https://esolangs.org/w/index.php?diff=80197&oldid=80108 5* 03Hakerh400 5* (+14) 10+[[Trivial]] > 1611371500 784699 PRIVMSG #esoteric :14[[07Trivial14]]4 M10 02https://esolangs.org/w/index.php?diff=80198&oldid=80195 5* 03Hakerh400 5* (+0) 10 < 1611371814 51455 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca QUIT :Ping timeout: 265 seconds < 1611373964 568843 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca JOIN :#esoteric < 1611373999 561821 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca QUIT :Remote host closed the connection < 1611375118 650593 :MDude!~MDude@71.50.47.112 QUIT :Quit: Going offline, see ya! (www.adiirc.com) < 1611376760 52312 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1611376840 492701 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1611376852 425123 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1611376859 999639 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : oh wow, so it turns out that if you pass MAP_NORESERVE to mmap (to tell it that it can find physical memory lazily as you write to your virtual memory, and don't need a guarantee that physical memory is available) < 1611376865 506443 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : Linux lets you allocate some really ridiculous amounts of memory, I managed 35 TB in a single block (with almost that much allocated in other blocks) < 1611376902 106390 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was hoping it would do that, it means that you can (in effect) use very large MAP_NORESERVE mmaps as a method of reserving address space < 1611376997 944336 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I remember that Linux has a reserve vs. commit distinction, just like Windows, but no one actually uses it. < 1611377028 892461 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So you can write Linux programs that reserve address space and commit it as necessary, and they run fine without overcommit. But almost no program does that because overcommit is so pervasive. < 1611377045 791929 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And it's not even possible to ask the kernel what a process's committed memory usage is. It's not anywhere in /proc. < 1611377106 622887 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think the trick is something like mapping pages PROT_READ or PROT_NONE so your process doesn't get charged for them. < 1611377131 986979 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was using MAP_NORESERVE | MAP_READ | MAP_WRITE for mine, that seemed to work < 1611377150 978902 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, I think /proc/$$/smaps might have the information you're looking for (although not directly) < 1611377171 336130 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But you want to be able to make a big mapping and then gradually commit it as you use more memory. < 1611377194 616544 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I think I looked in smaps and didn't find it. < 1611377204 425662 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But maybe I only looked in status? < 1611377232 143118 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't remember anymore. It would be nice if it was possible. < 1611377273 531335 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can use madvise, or flags to mmap, to actually load physical pages to back your address range < 1611377283 300419 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :I thought Linux will (by default) overcommit allocations even without special mmap flags < 1611377284 270088 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but normally you just let the kernel do it lazily < 1611377284 406174 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you disable overcommit, the OOM killer should be irrelevant, right? < 1611377308 301862 :kmc!~beehive@unaffiliated/kmcallister PRIVMSG #esoteric :ais523: see also mlock() and mlockall() < 1611377318 45730 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't really like the Linux culture of overcommit-and-pray. < 1611377328 778399 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, I wonder whether madvise(MADV_WILLNEED) on large blocks of memory is faster than just directly reading them and letting the kernel handle the pagefault < 1611377337 318346 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :presumably, pagefaults have some overhead as you switch to the kernel and back again < 1611377391 275738 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: sorry for my connection < 1611377403 394140 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1611377431 548919 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : If you disable overcommit, the OOM killer should be irrelevant, right? ← sort-of; you still get processes failing randomly but now it's the process that can't allocate memory, as opposed to the process the kernel chooses to pick on < 1611377448 387081 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because very few applications have any sensible codepath for the out-of-memory situation < 1611377452 934067 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's not random, that's a process asking for memory in a well-defined place and failing. < 1611377465 719491 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, what I mean is < 1611377472 311356 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess that's true, a lot of programs are buggy. < 1611377480 49973 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the process that dies is the next process that tries to allocate memory, which might not be the process responsible for the problem < 1611377504 718345 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :say you have a program that makes intermittent large allocations and it's using up basically all of memory < 1611377511 921406 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and a program that is using less memory but makes lots of small allocations < 1611377522 895023 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it is quite possibly the latter program that will hit an OOM situation first < 1611377533 720463 :ais523!~ais523@unaffiliated/ais523 QUIT :Client Quit < 1611377545 578571 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1611377554 494686 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :At least with this system people who write programs have a chance of making them work well. < 1611377570 788552 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm interested in why you think failing to handle OOM is a bug < 1611377605 994805 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :IMO, exiting in response to an OOM situation is usually correct (or possibly killing the process that's responsible for the memory, if it's not you) < 1611377611 792322 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, it's not a bug in every program, some programs just can't do anything. < 1611377647 834120 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there is also the question of, should the OS start swapping under heavy memory pressure? < 1611377659 543482 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But some programs can behave well. Maybe clearing a cache they have, or exiting gracefully. < 1611377671 478650 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :disk has much higher capacities than memory on most systems < 1611377691 474977 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I just want to be able to write a reliable program that uses memory -- maybe even without allocating at all after startup -- and doesn't fail. < 1611377734 486972 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in practice, I think I've seen an actual memory exhaustion only once, all the other times a program leaked more memory than the computer had, it basically ended up using the hard disk as a replacement for memory < 1611377758 926487 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which of course makes the system unusably slow, which is why the point of memory exhaustion is rarely reached in practice < 1611378000 59221 :Deewiant!~deewiant@de1.ut.deewiant.iki.fi QUIT :Ping timeout: 256 seconds < 1611378105 110529 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if your program doesn't allocate at all after startup, I don't see why the OOM-killer would pick on it < 1611378105 173430 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess the concern might be, maybe a program is using all of memory, and then other programs can't even start up, so you can't log in and kill the big program. < 1611378105 173475 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But the OOM killer doesn't seem like that great a solution. < 1611378105 173497 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the basic question is "what do you do when there's no more left of a shared resource?" < 1611378105 173515 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, for one, maybe it allocates from the kernel's perspective, even if it doesn't from its own. < 1611378105 194153 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Because at startup it mmaps 16GB of memory to use for its computations, and it doesn't fault it all right away. < 1611378105 226143 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Linux's default config won't let you allocate substantially more memory space than the computer has physical memory, even if you don't prefault it (unless you specify MAP_NORESERVE) < 1611378105 246162 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can go a little over, but not that much < 1611378105 246232 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I don't think that's true. < 1611378105 269725 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :GHC's runtime maps 1TB at startup now, I think? < 1611378105 269779 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I both read it in the documentation, and tested it a few tens of minutes ago < 1611378105 269800 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :presumably the very large maps are using MAP_NORESERVE < 1611378105 321401 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, interesting, maybe I'm just wrong on that and everyone uses NORESERVE. < 1611378105 384073 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, now I'm vaguely curious as to why the pagetables don't end up filling most of memory when you do that, perhaps they can be deduplicated or initialized lazily or something like that < 1611378105 454687 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You don't need anything to be in actual page tables, right? < 1611378105 475784 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can just store a big interval in the kernel and allocate the memory when addresses in that interval are faulted. < 1611378105 496244 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh right, you can access an address that isn't in the page tables at all and you just get a page fault < 1611378105 496325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which the kernel can handle by creating a page table < 1611378105 517016 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so the maps only need to exist wihtin the kernel < 1611378139 46896 :Deewiant!~deewiant@de1.ut.deewiant.iki.fi JOIN :#esoteric < 1611378179 388316 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: you *can* allocate large amounts of memory that way, but I still think it's a bad idea to implement malloc, because you put more hidden performance costs on the kernel that has to manage that address space than you'd have in a more traditional malloc implementation. It's a good esoteric experiment though. < 1611378200 534186 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess an interesting compromise would be for the OS to decide on a physical address that should back a particular piece of memory, but not actually clear it out or set up the pagetables until it's used < 1611378202 688220 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Interesting, I thought NORESERVE was the default behavior in Linux until now. < 1611378207 365365 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it can use the physical memory for storing caches until then < 1611378213 744593 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(With overcommit_memory set to 0.) < 1611378246 239913 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I'm expecting it to be more efficient, rather than less efficient, because of fewer system calls < 1611378249 509258 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the page faults happen either way < 1611378250 701423 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It would be nice to be able to ask, from a program, to actually really for real have the memory. < 1611378269 315414 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Writing to every page is probably enough? < 1611378279 74302 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And maybe mlocking it. < 1611378279 517911 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :overcommit_memory = 1 will noreserve everything; overcommit_memory = 2 will refuse to overcommit at all < 1611378306 243719 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mlocking is limited at 64 MB by default (although root can increase the limit at will) < 1611378321 81706 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think it makes sense that there's a limit for that < 1611378336 970511 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The default mlock limit is much higher than it used to be. < 1611378344 826291 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :max locked memory (kbytes, -l) 4062728 < 1611378358 470191 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :4 GB, wow < 1611378362 875139 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe you have more physical memory than I do < 1611378372 513796 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or one of us has it set to a non-default value somehow < 1611378377 323883 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I feel like it used to be 64 kB or something. < 1611378390 522365 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :max locked memory (kbytes, -l) 65536 < 1611378396 425513 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :from my ulimit -a < 1611378398 407702 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I have 32 GB of physical memory, using Ubuntu, Linux 5.8.0. < 1611378429 872711 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I have a lot less physical memory than you do, and am on Linux 5.4 < 1611378485 834382 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, part of the reason I was looking at this is that I'm considering creating a new executable loader, and was considering possible patterns for allocating the virtual address space < 1611378506 119371 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one possibility was to manage virtual memory reservations in userspace < 1611378538 795797 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could very efficiently do it statically, because virtual memory is so large that you can just divide it up evenly between every library that cares and they'll all have enough < 1611378575 699452 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: the page faults happen either way, but now the kernel has to manage a lot of administration structures to follow what is mapped where and set up page tables correctly, plus since the actual use is sparse, it can't use large pages, so the cpu has to work harder with paging table lookups too. < 1611378582 983643 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one vision I have is for programs to be able to use multiple memory allocators without them treading on each others' toes, and to have a unified free() which can free from any of them < 1611378606 185412 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: by default, the kernel never uses large pages < 1611378617 850597 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unless userspace requests it < 1611378619 811155 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Don't you typically know how memory was allocated when you free it? < 1611378652 574403 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I think it does use large pages these days on modern kernels. and even if it doesn't, an mmap implementation that allocates everything to a *dense* (non-sparse) region, it can request large pages. < 1611378657 117902 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: often but not always, unless you have extra variables tracking it < 1611378672 668294 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :`` ulimit -l # unit is kilobytes < 1611378674 420177 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0 < 1611378686 149951 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a good example is functions that return either a string literal or an allocated string < 1611378687 112765 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I feel like supporting multiple allocators is tricky, because many allocators don't have the same interface. < 1611378705 109502 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, the aim would be to define a standard interface for allocators < 1611378706 897603 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you use an arena allocator, you don't want to walk your entire data structure and call free() on each node. You want to avoid walking it at all. < 1611378716 952895 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :C already has one (malloc/calloc/realloc/free), but it kind-of sucks < 1611378740 950496 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, I meant in terms of general-purpose allocators; arena allocators often don't support frees at all < 1611378749 67096 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you free the arena, not the nodes < 1611378759 647101 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right, I meant free() would be a no-op (with a standard interface). < 1611378788 522951 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but take the example of, say, asprintf < 1611378801 665421 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(which returns malloc'ed memory of the size of the string) < 1611378813 37538 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't think that's a very good idea. the point is, we want to use sized allocators in programs that allocate a lot of small nodes on the heap, that is, allocators where the free function knows what size and alignment (and other parameters) were passsed to the allocate call, because this lets you allocate the small nodes with less memory overhead than when everything has to be tagged by at < 1611378819 43879 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :least the size. < 1611378821 567812 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that kind-of assumes there's a global allocator, because you don't want to need to have a matching asprintf_free < 1611378851 143324 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: so this is something I've been thinking about a lot < 1611378858 441451 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, most of the time mallocing individual strings like that isn't so great anyway. < 1611378874 302408 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :admittedly you prefer not to allocate a lot of small nodes, or if you do, you want to allocate them from a pool specific to the structure with context about that structure for free, but the latter exactly means no single free interface without parameters < 1611378888 828052 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :is the correct malloc/free interface: a) the allocator supports an efficient API to ask about the size of allocated memory, so that the program doesn't have to track it; or b) free takes an argument for the size of the thing you allocated, so that the allocator doesn't have to track it? < 1611378905 738823 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :free should take an argument for the size. < 1611378925 128421 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I think you want both kinds < 1611378940 693471 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :and also allocators that take a pool argument that you have to pass to free too < 1611378943 102590 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Also, the most flexible realloc interface is kind of complicated, I think. < 1611378944 875207 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :currently most people track in both places which is just ridiculous overhead < 1611378945 75809 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :various different allocators < 1611378966 658558 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For example, you might want to give realloc two different possible sizes, one if it can grow in place and one if it can copy. < 1611378970 419899 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :especially ones that serve my pet peeve, pool allocators that let you use 32-bit pointers or indexes into a poool < 1611379003 89259 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And you might want to ask, with a malloc-style interface, "what's the actual size of the allocated memory?", since it might be bigger than what you asked for, and you might be able to use that. < 1611379005 173267 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: I'm beginning to wonder whether "grow in place" is something that's worth optimising for at all < 1611379047 237709 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: anyway, one thing that crossed my mind is that if you're userspace managing the complete address space, you have control over what all the bits of a pointer mean, and, e.g. can encode the arena number in some of them < 1611379054 73090 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, not supporting realloc at all is another option, of course. < 1611379056 925187 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or even the size of the allocation < 1611379059 958301 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :also I'd like a sized allocator where alloc and free takes four size paramters, not just two: the size, the alignment, how many bytes you want readable without a segfault but with arbitrary content before the allocated region, and how many bytes you want readable after. and I want a pony. < 1611379096 385632 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, you can do that too in an interpreter. but you have to be careful so it doesn't slow down dereferencing too much. < 1611379104 34570 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: no, realloc is still helpful for large allocations, *but* if they're large enough to use mmap then the mremap doesn't require any copying behind the scenes, just a pagetable update < 1611379124 500880 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess. < 1611379140 138809 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In that sort of situation maybe you're better off reserving the entire size you might need upfront, and committing it as necessary. < 1611379143 286375 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So the address doesn't change. < 1611379150 400161 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: some interpreters, like ruby 1.8 and some lisp or prolog interpreters, already do this by using a tag bit that makes the pointer not a pointer but an integer. < 1611379178 746675 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: I've had further thoughts about your four-argument alloc: on 64-bit systems, just hardcode the readable-before and readable-after arguments to something large like 4GB, the extra argument passing is going to slow it down way more than not being able to use the very ends of the address space < 1611379215 972256 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't need as much as 4GB, but sure < 1611379244 216231 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I feel like you need at most 64 bytes before and after. < 1611379254 384671 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :shachaf: no, I want a full row of the pixmap < 1611379257 536937 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And even that's a lot. < 1611379258 943364 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :and a bit more < 1611379268 529997 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Ah, hmm. < 1611379270 985998 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my point is that providing a huge amount readable on both sides is very cheap on 64-bit processors < 1611379280 253958 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :because I want to reference the point above the currently iterated one < 1611379300 357435 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: yes, you have a point that constants instead of an argument make sense. < 1611379302 718012 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, I think some people who use malloc would prefer to have unreadable data around the allocation to help them diagnose accidental read-out-of-bounds < 1611379343 975641 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Ah, I remember an allocator that had an option for putting every allocation at the end of a page (or at the beginning). < 1611379363 89418 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the TLB would hate that :-D < 1611379401 960505 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Ah, this was it: https://ourmachinery.com/post/virtual-memory-tricks/ < 1611379406 328916 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :also I heard an anecdote that (an older version of) Sicstus prolog used tag bit(s) in the pointers, but ran into trouble because it used *high* bits instead of low bits as tag, which was fine at the start but later when people started to have a gigabyte or more memory on 32-bit machines, it turned out to be not such a great design after all < 1611379463 721529 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :AMD went to specific pains to try to stop people doing that when designing x86-64, for the reason you mention, and yet apparently some people are doing it anyway < 1611379490 98211 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: this was back in the 32-bit era < 1611379501 747910 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this despite the fact that 48-bit pointers have only just started to not be enough < 1611379532 903 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(Intel have stated plans to expand the pointer size to 57 bits, but AFAICT haven't yet released any processors with that size of pointer) < 1611379545 608916 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, maybe x86 will be dead by the time people use 72 TB of address space. < 1611379555 743676 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: haven't they already released on a few years ago? I'm not sure really > 1611379556 159367 PRIVMSG #esoteric :14[[07User:Language14]]4 10 02https://esolangs.org/w/index.php?diff=80199&oldid=80152 5* 03Quadril-Is 5* (+1044) 10Program that pushes 72 < 1611379563 34592 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, I thought several CPUs already used 56-bit addresses. < 1611379597 221367 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Linux has support for them added already, but it tends to add support for processor features before the actual processor is released < 1611379627 700525 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(57-bit x86-64, that is) < 1611379644 840030 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :page tables are 512 entries long on x86-64, so the pointer sizes go up 9 bits at a time < 1611379654 828801 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :"The extension was first implemented in the Ice Lake processors,[2] and the 4.14 Linux kernel adds support for it.[3]" < 1611379668 900799 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I haven't heard of Ice Lake < 1611379687 327885 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :September 2020 < 1611379694 348813 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, that's recent enough that I'm not surprised I missed it < 1611379708 650345 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Apparently new Intel chips are using 12-way set associative L1D caches. < 1611379752 683768 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe because (apparently) with their VIPT cache design, the cache size is the number of ways * the page size, so the only way to grow the cache is to increase the number of ways. < 1611379784 418343 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :shachaf: oh wow < 1611379791 6894 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :I thought that was impossible < 1611379818 526610 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :shachaf: and yes, that's the problem with x86, no way to guarantee that ALL pages on the system will be larger than 4k sized < 1611379829 236767 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :so the L1 cache can only be 32k < 1611379837 765801 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :growing the number of sets by a factor X would give you a cache that requires less space on the chip, but would be more likely to evict things due to set collisions, compared to growing the number of ways by a factor X < 1611379863 926980 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But they can't just grow the number of sets. < 1611379865 369340 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :it makes sense, it's just one of the sad realities we have to face because of historical binary compatibility < 1611379866 633034 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: in theory there's no reason why the L1 cache and page size should have anything to do with each other, although I gather that Intel have some sort of design that links them < 1611379893 442522 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I think it's the natural thing with VIPT caches, which I think are very standard. < 1611379907 874803 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Though I think some people have gotten around it with trickery. < 1611379928 798288 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the L1 cache is caching virtual addresses, it's the TLB that caches virtual→physical correspondences < 1611379966 582861 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I think there is a good reason, in that you want the L1 cache to have very low latency, as in just a few cycles (otherwise it's an L2 cache, not an L1 cache; and also ideally the ability to do two simultaneous reads), and for that you want to pick the cache line before the physical address physically arrives from the TLB cache < 1611379981 362219 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, but in order to get cache lookups fast enough, you want to start doing the lookup in parallel with TLB translation. < 1611379990 675337 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So you can only use virtual bits of the address for it. < 1611380004 130943 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: no, afaiu the L1 cache is caching physical addresses. it has to, because the process can write the same memory mapped at two different virtual addresses < 1611380005 476914 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: L1 cache typically works purely off the virtual address for that reason < 1611380013 568970 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's L2 and L3 that work off physical addresses < 1611380033 9109 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :it has to determine the cache line from virtual address, but then verify that the physical address matches or else it can produce incorrect results < 1611380038 269229 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, maybe this is one of those Intel versus AMD decisions? < 1611380047 73764 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't know of any x86 CPUs using VIVT sorts of L1 caches. < 1611380049 40957 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :at least for writable memory < 1611380056 269563 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Which I think is what you're describing? < 1611380064 179993 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :could be < 1611380067 258658 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I mean L1D, maybe L1I is different. < 1611380070 424478 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :maybe the L1C cache works with virtual addresses, because L1C can afford to be very slow and flush everything when a cached page is written < 1611380080 504368 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right. < 1611380087 13065 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :part of the problem is that the information about this that you find online has highly varying ages which often aren't clear < 1611380096 542464 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: I don't think it's an intel vs AMD thing < 1611380124 519389 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I asked about this on Twitter and it turned into a long thread with a hundred replies from some people who have more of an idea than I do. < 1611380127 62988 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, L1C shouldn't be expecting writes at all, and I think it's generally accepted that a write to code memory is one of those things that can reasonably cause a full pipeline stall < 1611380133 143307 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But my conclusion was that it's pretty complicated. < 1611380145 198011 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :but I admit I don't really understand this, so all I'm saying is just guesses that you shouldn't trust < 1611380158 161961 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: accepted and well documented < 1611380186 782474 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: yes, I mean it's documented, but people also agree that this is a decision that should have been made < 1611380187 169665 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :the only reason x86 even has to _detect_ writes to cached code pages is for historical compatibility with 386 < 1611380196 302733 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whereas some things are documented but look bizarre < 1611380202 318706 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: yeah < 1611380256 188464 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :like the thing where intel and AMD recommends different instructions as multibyte NOPs. if they can agree on all the instruction set, why can't they agree on that? sure, their instruction decoders are very different, but still < 1611380285 513264 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :couldn't they agree on something that's fast on both brands? < 1611380330 930155 :S_Gautam!uid286066@gateway/web/irccloud.com/x-xmmulthtorccjvqv JOIN :#esoteric < 1611380331 964325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think there's a "core" of NOP options which should be fast on both, but it only gets you up to 10 bytes or so < 1611380374 303870 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :right, but you want NOPs up to 15 byte long for padding < 1611380389 560866 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like, it's perfecly legal to put 5 CS: prefixes on a NOP, and Intel and AMD processors will decode this, but the decoders don't like it so neither processor manufacturer recommends you do that < 1611380405 182887 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think 5, might be limited to 4, I can't remember < 1611380408 610952 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :yes, this is about efficient NOPs, not valid nops < 1611380439 848677 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :having stared at instruction encodings for several days now, I'm pretty sure that 66 logically "should" be the fastest prefix < 1611380459 359440 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :anyway, this is an interesting conversation but I really ought to sleep < 1611380461 270947 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :g'nite < 1611380466 376227 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :followed by F2/F3, but F3 NOP already means something else < 1611380476 608686 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0xf3, 0x90 < 1611380477 926391 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: f3 90 pause < 1611380485 443282 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, that's rep. < 1611380492 734849 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yep < 1611380497 779892 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0xf2, 0x90 < 1611380498 867797 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: f2 90 repnz nop < 1611380525 60732 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is the sort of sequence that would often be repurposed as a nop with side effects < 1611380573 23978 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0xf3, 0x0f, 0x1e, 0xfa < 1611380574 144292 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: f3 0f 1e fa endbr64 < 1611380594 834691 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does that fit the NOP encoding? it's meant to be backwards-compatible as a NOP < 1611380620 64838 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah no, NOP would be 0F 1F < 1611380651 842377 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe it's an undocumented 8-bit NOP < 1611380662 737192 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x0f, 0x1e, 0xfa < 1611380663 875960 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1e fa nop %edx < 1611380689 535808 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :noe I'm really confused < 1611380765 77232 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :FA is 11 / 111 / 010, so that's "direct register access, R=7, B=2"; B is used as the input for a 1-argument instruction so 2 = %edx makes sense < 1611380807 63977 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but R is set to 7 when it should be 0 according to the documentation, and the LSB of the opcode is 0 when it should be 1 according to the documentation < 1611380841 287261 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :probably Intel is hanging on to a whole 15 undocumented NOP combinations so that they can allocate them for instructions that need to retroactively become NOPs < 1611380863 481939 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, backwards-compatibly be treated as NOPs < 1611380868 844144 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nop %edx < 1611380870 96793 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f c2 nop %edx < 1611380875 846354 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nop %dl < 1611380877 28841 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `nop' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: operand size mismatch for `nop' < 1611380878 951388 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0x0f, 0x1e, 0072 < 1611380880 187747 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1e 3a nopl (%rdx) < 1611380896 149085 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0x0f, 0x1e, 0002 < 1611380897 291524 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1e 02 nopl (%rdx) < 1611380902 941702 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0x0f, 0x1e, 0302 < 1611380904 72453 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1e c2 nop %edx < 1611380908 324498 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm. < 1611380953 421506 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think i misremembered how modr/m bytes work. < 1611380996 540646 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :top two bits are an enum that specify a) whether there's a memory access involved (only 11 doesn't access memory), b) whether there's a constant being added to the memory address and if so how many bytes it's written as < 1611381025 306150 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :next three bits are R, which is a register argument to the instruction (always a register) if it takes 2 or more arguments, and part of the opcode if it takes only 1 argument < 1611381032 709011 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right, I confused 11 with 00. < 1611381051 874129 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :bottom three bits are usually B, which is also a register argument to the instruction, and always used < 1611381064 334616 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the values of 101 and 100 are special cases < 1611381126 693459 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :101 means that there's a SIB byte, used to specify more complicated addressing (it corresponds to %esp, so you can't read from stack memory without a SIB byte) < 1611381167 292870 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :100 normally means %ebp, but the special case of 00 / xxx/ 100 means that there's no register at all, it's using a 32-bit immediate as the address instead < 1611381185 301729 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so if you want an access via %ebp you always have to explicitly give an offset from it < 1611381190 487058 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wrote an encoder for all this a couple of years ago, but clearly the details have slipped my memory. < 1611381199 678350 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (%ebx) < 1611381200 821384 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 67 0f 1f 03 nopl (%ebx) < 1611381205 693498 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (%rbx) < 1611381206 835717 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 03 nopl (%rbx) < 1611381208 874468 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (%rbp) < 1611381210 69567 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 45 00 nopl 0x0(%rbp) < 1611381212 69068 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (%rsp) < 1611381213 285462 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 04 24 nopl (%rsp) < 1611381235 577203 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :%rsp also corresponds to r12 or r13 or so, which has the same encoding issue. < 1611381243 149916 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1611381262 377221 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because the fourth bit of R and B is in the REX prefix, not part of the ModRM byte < 1611381272 847506 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right. < 1611381302 263324 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What a mess. < 1611381305 624870 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm rex.x nopl (%rax) < 1611381306 753355 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 42 0f 1f 00 rex.X nopl (%rax) < 1611381329 64965 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is the one case of encoding that confuses me < 1611381337 908932 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm rex.x nopl (%rax, %r12, 1) < 1611381339 75992 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: same type of prefix used twice \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: no such instruction: `nopl (%rax,%r12,1)' < 1611381344 109638 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (%rax, %r12, 1) < 1611381345 328543 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 42 0f 1f 04 20 nopl (%rax,%r12,1) > 1611381347 87500 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80200&oldid=80161 5* 03Quadril-Is 5* (+9) 10/* Something */ > 1611381367 89754 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80201&oldid=80200 5* 03Quadril-Is 5* (+0) 10/* Something */ < 1611381382 820073 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :normally %rsp as X is used to write a null SIB byte that does nothing (this is only useful in the case when you want %rsp as B, as far as I can tell, or to pad out space) < 1611381399 311537 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but %r12 as X is *not* a special case, it actually uses %r12 < 1611381406 271478 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x0f, 0x1f, 0x04, 0x20 < 1611381407 443410 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 04 20 nopl (%rax,%riz,1) < 1611381425 311480 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :huh, %riz, that's a new one (must be "integer zero") < 1611381457 572388 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, I remember this. I think the assembler doesn't even accept it as input. < 1611381490 683728 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm nopl (%rax,%riz,1) < 1611381491 948047 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: bad register name `%riz' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: no such instruction: `nopl (%rax,%riz,1)' < 1611381502 754460 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`asm .byte 0x0f, 0x1f, 0004, 0240 < 1611381503 924324 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 04 a0 nopl (%rax,%riz,4) < 1611381542 663097 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so ModRM+SIB bytes of 00xxx100 00100yyy and the single ModRM byte 00xxxyyy are identical in *almost* every context < 1611381548 633776 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :except when you have a rex.x prefix < 1611381576 247180 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I hate this sort of special case, because i'm hoping to have a domain-specific language for instruction encoding and this sort of thing just blows it up < 1611381603 57595 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl(%rax,,1) < 1611381607 749804 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid character '(' in mnemonic \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid character '(' in mnemonic < 1611381613 306626 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (%rax,,1) < 1611381617 298126 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: expecting scale factor of 1, 2, 4, or 8: got `' \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: no such instruction: `nopl (%rax,,1)' < 1611381634 478234 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl (,%rax,1) < 1611381635 883260 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 0f 1f 04 05 00 00 00 00 nopl 0x0(,%rax,1) < 1611381643 201961 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what an inconsistent syntax :_D < 1611381697 479976 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's funny. < 1611381720 617878 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also I didn't even realise whitespace was significant there < 1611381720 718296 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wonder why they introduced riz. < 1611381734 361393 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Whitespace is significant? < 1611381741 948013 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, those are different errors. < 1611381742 77443 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm nopl(,%rax,1) < 1611381743 812129 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid character '(' in mnemonic \ /tmp/asm.s: Assembler messages: \ /tmp/asm.s:1: Error: invalid character '(' in mnemonic < 1611381768 945848 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I have been tempted to invent my own asm syntax, with = signs after output arguments < 1611381776 101944 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so that I don't keep forgetting which way the arguments go < 1611381789 461787 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm used to AT&T syntax but I should probably switch to Intel syntax. < 1611381799 818143 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :would also help differentiate between the two encodings of register-register MOV < 1611381800 44634 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Since that way I can just read the Intel manual. < 1611381833 842930 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't like the whole "dword ptr [...]" thing in Intel syntax. < 1611381870 894503 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm .byte 0x8b, 0xc1, 0x89, 0xc8 < 1611381872 108365 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 8b c1 mov %ecx,%eax \ 2: 89 c8 mov %ecx,%eax < 1611381896 934198 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are probably no processors where this difference matters, but it still feels wrong that you can't specify < 1611381901 842356 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`asm mov %ecx, %eax < 1611381905 456414 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :0: 89 c8 mov %ecx,%eax < 1611381935 386174 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I like the way AT&T syntax gives instructions length suffixes, but remembering the suffixes is hard < 1611381945 40092 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I might just use mov64 and so on. < 1611381956 485634 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, I think that's an improvement < 1611381963 261787 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's what I did in my C library. < 1611381971 413698 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or logarithms, mov3 for bytes, mov4 for words, mov5 for dwords, mov6 for qwords < 1611382005 945560 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` echo 'long foo(long x) { return x; }' | gcc -x c /dev/stdin -o /tmp/foo.o && objdump -d /tmp/foo.o | grep mov < 1611382008 96262 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': \ (.text+0x20): undefined reference to `main' \ collect2: error: ld returned 1 exit status < 1611382011 225872 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the better reason to put the width on the opcode, though, is then you can stop changing the name of a register every time you access it with a different width < 1611382015 197304 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` echo 'long foo(long x) { return x; }' | gcc -c -x c /dev/stdin -o /tmp/foo.o && objdump -d /tmp/foo.o | grep mov < 1611382016 657896 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​ 1: 48 89 e5 mov %rsp,%rbp \ 4: 48 89 7d f8 mov %rdi,-0x8(%rbp) \ 8: 48 8b 45 f8 mov -0x8(%rbp),%rax < 1611382024 480425 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Ugh. < 1611382029 622022 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` echo 'long foo(long x) { return x; }' | gcc -Os -c -x c /dev/stdin -o /tmp/foo.o && objdump -d /tmp/foo.o | grep mov < 1611382031 83170 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​ 0: 48 89 f8 mov %rdi,%rax < 1611382037 54132 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` echo 'long foo(long x) { return x; }' | clang -Os -c -x c /dev/stdin -o /tmp/foo.o && objdump -d /tmp/foo.o | grep mov < 1611382038 163713 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/hackenv/bin/`: line 5: clang: command not found < 1611382056 8953 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: IIRC gcc and clang use the same assembler as each other, at least on Linux, so you'll get the same output < 1611382072 20586 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :clang doesn't use its own assembler? < 1611382074 349353 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :llvm-as or something? < 1611382080 652745 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, maybe it does < 1611382107 472955 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah no, llvm-as works on LLVM bitcode, not x86-64 instructions < 1611382132 409922 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, hmm. < 1611382138 736048 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What does llvm use on Windows? < 1611382150 237319 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I thought it had its own assembler. < 1611382156 346219 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It has llvm-mc which includes an assembler, right? < 1611382168 212602 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess it could just use masm < 1611382181 301622 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but shipping an assembler would also make sense < 1611382182 600508 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Doesn't it support inline assembly? < 1611382192 609986 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes but it's literally quoted into the assembler input < 1611382195 463957 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Which I'd expect to be portable rather than use the platform syntax. < 1611382339 944933 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` echo 'long foo(long x) { asm("sal %0, $1 // test" : "+r" (x)); return x }' | gcc -S -o /tmp/t.s; cat /tmp/t.s < 1611382341 57750 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :gcc: fatal error: no input files \ compilation terminated. \ cat: /tmp/t.s: No such file or directory < 1611382350 368103 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` echo 'long foo(long x) { asm("sal %0, $1 // test" : "+r" (x)); return x }' | gcc -S -o /tmp/t.s -x c /dev/stdin; cat /tmp/t.s < 1611382351 860701 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/dev/stdin: In function ‘foo’: \ /dev/stdin:1:66: error: expected ‘;’ before ‘}’ token \ cat: /tmp/t.s: No such file or directory < 1611382382 133260 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` echo 'long foo(long x) { asm("sal %0, $1 // test" : "+r" (x)); return x; }' | gcc -S -o /tmp/t.s -x c /dev/stdin; cat /tmp/t.s < 1611382383 371824 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​ .file "stdin" \ .text \ .globl foo \ .type foo, @function \ foo: \ .LFB0: \ .cfi_startproc \ pushq %rbp \ .cfi_def_cfa_offset 16 \ .cfi_offset 6, -16 \ movq %rsp, %rbp \ .cfi_def_cfa_register 6 \ movq %rdi, -8(%rbp) \ movq -8(%rbp), %rax \ #APP \ # 1 "/dev/stdin" 1 \ sal %rax, $1 // test \ # 0 "" 2 \ #NO_APP \ movq %rax, -8(%rbp) \ movq -8(%rbp), %rax \ popq %rbp \ .cfi_def_cfa 7, 8 \ ret \ .cfi_endproc \ .LFE0: \ .size < 1611382391 72407 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :see, the comment got copied into the output file < 1611382402 789036 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, I know. < 1611382410 619421 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` echo 'long foo(long x) { asm("%0!" : "+r" (x)); return x; }' | gcc -S -o /tmp/t.s -x c /dev/stdin; cat /tmp/t.s < 1611382411 821078 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​ .file "stdin" \ .text \ .globl foo \ .type foo, @function \ foo: \ .LFB0: \ .cfi_startproc \ pushq %rbp \ .cfi_def_cfa_offset 16 \ .cfi_offset 6, -16 \ movq %rsp, %rbp \ .cfi_def_cfa_register 6 \ movq %rdi, -8(%rbp) \ movq -8(%rbp), %rax \ #APP \ # 1 "/dev/stdin" 1 \ %rax! \ # 0 "" 2 \ #NO_APP \ movq %rax, -8(%rbp) \ movq -8(%rbp), %rax \ popq %rbp \ .cfi_def_cfa 7, 8 \ ret \ .cfi_endproc \ .LFE0: \ .size foo, .-foo \ . < 1611382428 424843 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the syntax doesn't have to make any sense < 1611382430 506556 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I just meant that I suspect the assembly syntax that clang lets you embed is consistent between Linux and Windows, so I doubt it just uses masm. < 1611382448 653002 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I suspect it's different > 1611382472 726281 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80202&oldid=80201 5* 03Quadril-Is 5* (-9) 10/* Something */ < 1611382516 847873 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Besides, it supports cross-compiling, right? < 1611382567 454232 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm. < 1611382588 273658 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` echo 'long foo(long x) { asm(".syntax intel\nmov eax, eax" : "+r" (x)); return x; }' | gcc -c -S -o /tmp/t.s -x c /dev/stdin; cat /tmp/t.s < 1611382589 644499 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​ .file "stdin" \ .text \ .globl foo \ .type foo, @function \ foo: \ .LFB0: \ .cfi_startproc \ pushq %rbp \ .cfi_def_cfa_offset 16 \ .cfi_offset 6, -16 \ movq %rsp, %rbp \ .cfi_def_cfa_register 6 \ movq %rdi, -8(%rbp) \ movq -8(%rbp), %rax \ #APP \ # 1 "/dev/stdin" 1 \ .syntax intel \ mov eax, eax \ # 0 "" 2 \ #NO_APP \ movq %rax, -8(%rbp) \ movq -8(%rbp), %rax \ popq %rbp \ .cfi_def_cfa 7, 8 \ ret \ .cfi_endproc \ .LFE0: \ < 1611382615 574029 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :For some reason I thought it restored the syntax to att automatically. I guess not. < 1611382631 912391 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: I just checked Clang's documentation about asm commands < 1611382650 43232 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it is a literal hyperlink to gcc's documentation about asm commands, on gcc's website < 1611382695 568404 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so I'd expect it to work the same way; if it worked differently it should at least be documented? > 1611382891 717131 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80203&oldid=80202 5* 03Quadril-Is 5* (+5) 10/* Something */ < 1611383007 189686 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, some searches imply that clang's inline asm always uses AT&T syntax, even on Windows, so probably it does have its own assembler > 1611383026 470386 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80204&oldid=80203 5* 03Quadril-Is 5* (+8) 10/* Something */ > 1611383072 632260 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80205&oldid=80204 5* 03Quadril-Is 5* (+36) 10/* Something */ < 1611383088 271002 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`` type llvm-mc > 1611383088 791511 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80206&oldid=80205 5* 03Quadril-Is 5* (-30) 10/* Something */ < 1611383089 591924 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :​/hackenv/bin/`: line 5: type: llvm-mc: not found > 1611383323 553648 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80207&oldid=80206 5* 03Quadril-Is 5* (+169) 10/* Something */ < 1611383387 818767 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It seems ridiculous to me that there's any compiler anywhere that doesn't support cross-compiling. > 1611383466 550376 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80208&oldid=80207 5* 03Quadril-Is 5* (+149) 10/* Invalid links */ > 1611383536 220622 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80209&oldid=80208 5* 03Quadril-Is 5* (+6) 10/* Special characters */ > 1611383544 986321 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80210&oldid=80209 5* 03Quadril-Is 5* (+6) 10/* Special characters */ < 1611383639 793106 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: presumably, to cross-compile, any inline asm would have to be written for the target platform < 1611383650 765096 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure, of course. < 1611383675 162445 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(Though Windows and Linux can share x86-64 assembly.) > 1611383691 454250 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80211&oldid=80210 5* 03Quadril-Is 5* (+20) 10/* Special starting things */ < 1611383692 192514 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, my experience is that compilers themselves normally support cross-compiling, but the toolchains surrounding them (especially the build tools) often don't < 1611383740 427233 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Windows and Linux have different calling conventions, so you could share inline asm but only as long as it didn't call functions and wasn't a function itself < 1611383750 186714 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure. < 1611383772 401687 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Toolchains and build tools should definitely support cross-compiling. > 1611383796 842682 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80212&oldid=80211 5* 03Quadril-Is 5* (-25) 10/* Special starting things */ < 1611383939 331781 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :with compilers it's even harder because you have three platforms to deal with (compiler build, compiler run = target program build, target program run) > 1611383967 514601 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80213&oldid=80212 5* 03Quadril-Is 5* (+14) 10/* Special starting things */ > 1611383982 280579 PRIVMSG #esoteric :14[[07Esolang:Sandbox14]]4 10 02https://esolangs.org/w/index.php?diff=80214&oldid=80213 5* 03Quadril-Is 5* (-97) 10/* Bad title */ < 1611383994 727283 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I managed to get C-INTERCAL to support compiler build != compiler run (it was hard, and involves what is in effect two independent autoconf scripts) < 1611384019 856855 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it doesn't directly support target build != target run yet, though < 1611384462 174559 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :btw, I figured out why sharing libc.so between a lot of programs is helpful: it's not specifically to save memory nowadays, but to increase the chance that commonly used bits of libc are in the L2 cache < 1611384479 613350 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also, the L3 cache, and main memory) < 1611384498 553438 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so program startup is faster because it doesn't have to copy in libc from disk every time, like it would in a statically linked program < 1611384508 843878 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Are cache misses on libc really a significant part of the runtime of programs? < 1611384517 800609 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or startup time, I guess. < 1611384529 635576 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it wouldn't surprise me if they were, for small programs that run quickly < 1611384549 653026 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :disk access is so much slower than just about anything else < 1611384550 260922 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :My guess is that it's negligible for almost all programs. < 1611384556 865697 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But it would be interesting to measure. < 1611384583 355040 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I wonder how you evict a particular file from memory altogether on Linux < 1611384596 454082 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(ideally without affecting the rest of the system in the process) < 1611384606 282072 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I only know how to evict the entire cache. < 1611384667 744904 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could get the file out of L3 cache by mmapping it, faulting it in, then clflushing every cache line in it < 1611384675 403254 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(that will also take it out of L1 and L2 caches) < 1611384688 441846 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :getting it out of main memory seems harder, though (especially as you just faulted it in there!) < 1611384706 14924 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe if you write to it with O_DIRECT. < 1611385344 631868 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1611385448 120736 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I've been looking for a way in the Linux kernel sources, but haven't found one (that said, I'm terrible at finding anything in there) < 1611388192 514482 :imode!~imode@unaffiliated/imode QUIT :Quit: Sleep. < 1611388449 496902 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit > 1611388617 252258 PRIVMSG #esoteric :14[[07Truth-machine14]]4 10 02https://esolangs.org/w/index.php?diff=80215&oldid=80183 5* 03Hakerh400 5* (+259) 10+[[Trivial]] > 1611388739 495392 PRIVMSG #esoteric :14[[07Truth-machine14]]4 M10 02https://esolangs.org/w/index.php?diff=80216&oldid=80215 5* 03Hakerh400 5* (+25) 10/* Trivial */ > 1611388773 380253 PRIVMSG #esoteric :14[[07Truth-machine14]]4 M10 02https://esolangs.org/w/index.php?diff=80217&oldid=80216 5* 03Hakerh400 5* (+1) 10/* Trivial */ < 1611391110 644751 :S_Gautam!uid286066@gateway/web/irccloud.com/x-xmmulthtorccjvqv QUIT :Quit: Connection closed for inactivity < 1611392114 233610 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com JOIN :#esoteric < 1611392144 19312 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :" actually, my experience is that compilers themselves normally support cross-compiling, but the toolchains surrounding them (especially the build tools) often don't" => this yes, except it's even more the system libraries than the build tools. gcc and clang in theory works fine on or for windows, but it's very hard to actually use them on windows because of lack of a good toolchain that works < 1611392150 65592 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :with them. and gcc/clang, for some reason, still only supports the ABI where long is 64-bit on windows, so you can't just mix and match it with native windows toolchains. it's strange, you'd think it would be trivial to add a separate mode to them where long is 32-bit long (plus implement the remaining builtin functions and pragmas for msvc compatibility), but that's not happening. < 1611392213 294398 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :I am sort of hoping that https://ziglang.org/ will fix this: it promises to ship a working C compiler toolchain based on clang and a custom libc to windows, but it does not, at least right now, try to ship a C++ compiler toolchain < 1611392324 182926 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :"I wonder how you evict a particular file from memory altogether on Linux" => perhaps with fadvise or posix_madvise, or by truncating it to zero length < 1611392339 6232 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :but that won't work for libc < 1611392679 520749 :none30!none30matr@gateway/shell/matrix.org/x-wbdhirkglvjiifjr QUIT :*.net *.split < 1611392680 523307 :myname!~myname@2001:41d0:1:766f::1 QUIT :*.net *.split < 1611392692 305925 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :ais523: opening the library and then posix_fadvise(.., .., .., POSIX_FADV_DONTNEED) might work, but this is only good for read-only files like a shared library, otherwise it has the side effect of possibly discarding cached writes < 1611392796 873010 :none30!none30matr@gateway/shell/matrix.org/x-wbdhirkglvjiifjr JOIN :#esoteric < 1611392796 873099 :myname!~myname@2001:41d0:1:766f::1 JOIN :#esoteric < 1611393000 768950 :Discordian[m]!discordi1@gateway/shell/matrix.org/x-pokzxgqakjzigxrv QUIT :Ping timeout: 244 seconds < 1611393012 349836 :wmww!wmwwmatrix@gateway/shell/matrix.org/x-dtflfosnicdvvdzx QUIT :Ping timeout: 243 seconds < 1611393022 949948 :none30!none30matr@gateway/shell/matrix.org/x-wbdhirkglvjiifjr QUIT :Ping timeout: 258 seconds < 1611393028 255927 :acedic[m]!acedicmatr@gateway/shell/matrix.org/x-soltyfoqqaqxskbx QUIT :Ping timeout: 265 seconds < 1611393766 22975 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 272 seconds < 1611394636 944621 :none30!none30matr@gateway/shell/matrix.org/x-isertcberoxcbevs JOIN :#esoteric < 1611394752 788082 :Discordian[m]!discordi1@gateway/shell/matrix.org/x-brbjipzvdtrvdatz JOIN :#esoteric < 1611395074 245738 :LKoen!~LKoen@57.174.9.109.rev.sfr.net JOIN :#esoteric < 1611395121 654405 :acedic[m]!acedicmatr@gateway/shell/matrix.org/x-mnxzbbkkidslomox JOIN :#esoteric < 1611395757 37062 :none30!none30matr@gateway/shell/matrix.org/x-isertcberoxcbevs QUIT :Ping timeout: 240 seconds < 1611395764 824672 :acedic[m]!acedicmatr@gateway/shell/matrix.org/x-mnxzbbkkidslomox QUIT :Ping timeout: 240 seconds < 1611395766 105745 :Discordian[m]!discordi1@gateway/shell/matrix.org/x-brbjipzvdtrvdatz QUIT :Ping timeout: 246 seconds < 1611396701 391292 :rain1!~My_user_n@unaffiliated/rain1 JOIN :#esoteric < 1611397280 281615 :none30!none30matr@gateway/shell/matrix.org/x-tzrmrpncvuazymhz JOIN :#esoteric < 1611398434 475998 :mniip!~mniip@freenode/staff/mniip QUIT :Ping timeout: 606 seconds < 1611398878 575856 :acedic[m]!acedicmatr@gateway/shell/matrix.org/x-nrsfsqmwpvuiwgsc JOIN :#esoteric < 1611398878 637671 :wmww!wmwwmatrix@gateway/shell/matrix.org/x-kcuwpneysfpfzstz JOIN :#esoteric < 1611398879 563394 :Discordian[m]!discordi1@gateway/shell/matrix.org/x-auuhilbfuixiizab JOIN :#esoteric < 1611400269 71481 :ArthurStrong!~ArthurStr@188.163.100.177 QUIT :Quit: leaving < 1611403568 548021 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com QUIT :Quit: Leaving < 1611404124 993139 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :hey #estoeric, I have a question about Android UI since I don't generally use Android computers. you know how Android generally has three buttons at the bottom of the screen, these used to be physical buttons but these days they're just software ones? have they changed this such that the third button besides back and home screen is no longer the menu button, when did they change this, and how could they < 1611404130 996718 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :change something without breaking compat with all existing third party programs? < 1611404165 810027 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :I think mostly the third party programs don't use the buttons < 1611404181 731250 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :like, your program may provide a functionality that must be called when the user hits the button "return" < 1611404227 281432 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :but the program itself just provide a functionality that corresponds to "return" and whether the user presses the button or returns by some other way is unknown < 1611404236 516275 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :I meant "back" not "return" < 1611404260 741179 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :and does that apply to the menu button as well? < 1611404268 697459 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :on my phone the third button is "view all opened windows" < 1611404274 262440 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :I've never had a "menu" < 1611404350 662394 :LKoen!~LKoen@57.174.9.109.rev.sfr.net PRIVMSG #esoteric :but then I haven't had an android for very long. I used to have a phone with 12 buttons that could only send text messages and phone calls < 1611404660 305954 :myname!~myname@2001:41d0:1:766f::1 PRIVMSG #esoteric :b_jonas: do you perhaps use a modified android version provided by the manufactorer of your phone? < 1611404700 454630 :myname!~myname@2001:41d0:1:766f::1 PRIVMSG #esoteric :i vaguely remember switching longpress and single press on some of those buttons on some ui modifications < 1611404709 302380 :myname!~myname@2001:41d0:1:766f::1 PRIVMSG #esoteric :but it should be reversible via settings < 1611404861 721524 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :myname: my phone doesn't have any Android version thank you very much < 1611406010 527603 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :There's three versions of Android navigation that have been in the stock AOSP builds: 3-button navigation, 2-button navigation and gesture navigation. < 1611406052 520438 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I don't remember exactly which version included which one, and which ones are still available. I think at least one of my phones still offers all three. (It's a configurable setting.) < 1611406206 248257 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :fizzie: what does 3-button navigation mean? < 1611406215 639071 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :so this is still configurable? ok < 1611406245 895693 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :It's the one that has the three buttons "back", "home" and "recent apps" (which is officially called "overview", but I don't think that is such a well-known term). < 1611406256 334815 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I've never seen the third button to be "menu" either. < 1611406289 518467 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :But manufacturers do tend to do all kinds of UI customizations. I think I had a test device with four buttons once. < 1611406381 790567 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Looking around, though, apparently they did used to have that in AOSP too, just longer ago than when I got into Android (pre-Lollipop). < 1611406433 222089 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :As for "without breaking compat", I don't imagine they did, but it *has* been a long time now. < 1611406447 7341 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :https://developer.android.com/guide/topics/ui/menus "Beginning with Android 3.0 (API level 11), Android-powered devices are no longer required to provide a dedicated Menu button. With this change, Android apps should migrate away from a dependence on the traditional 6-item menu panel and instead provide an app bar to present common user actions." < 1611406484 515388 :myname!~myname@2001:41d0:1:766f::1 PRIVMSG #esoteric :well, it can only "break compatibility" to the user, the apps aren't really aware of the navigation besides some signals < 1611406514 31480 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I mean, they can expect there to be a menu button and not provide any other way to launch some functionality. < 1611406523 350230 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :So I think that'd be pretty much a breaking change. < 1611406550 131419 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :s/can/could, back then,/ < 1611406591 165715 :myname!~myname@2001:41d0:1:766f::1 PRIVMSG #esoteric :ah the three-dots-one, if i remember correctly, that was a per-app thing. i have no idea if it is actually removed < 1611406608 911821 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :It wasn't a three-dots initially. < 1611406785 478877 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :AFAICT, it was one of the three primary buttons (in the pre-ICS days), with a menu symbol. Then it got shifted to be an "overflow" three dots thing (in *addition* to the three main buttons, only shown if the app defines an options menu), and then gotten rid of completely. < 1611406991 582183 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :https://developer.android.com/guide/topics/ui/menus#options-menu "Where the items in your options menu appear on the screen depends on the version for which you've developed your application: ..." < 1611407043 661445 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :That makes me wonder what would happen if I could still find an app with targetSdk=10 and run it on a modern phone, would it provide some system UI affordance to show the menu. < 1611407158 963341 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :fizzie: I see < 1611407162 446854 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :If it does (or at least did for a while), then I guess that's the way they could make that change without breaking compatibility: by treating apps that target a version of the platform where a menu button was still mandatory differently. (If you declare targetSdk >= 11, you presumably promise it will work even without a menu button.) < 1611407223 888904 :b_jonas!~a@catv-176-63-12-49.catv.broadband.hu PRIVMSG #esoteric :makes sense < 1611407270 18658 :MDude!~MDude@71.50.47.112 JOIN :#esoteric < 1611408623 267901 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 JOIN :#esoteric < 1611409163 962646 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru JOIN :#esoteric < 1611410011 139203 :SpaceDecEva!2fca62a2@47.202.98.162 JOIN :#esoteric < 1611410114 609214 :SpaceDecEva!2fca62a2@47.202.98.162 QUIT :Client Quit < 1611410246 647174 :SpaceDecEva!2fca62a2@47.202.98.162 JOIN :#esoteric < 1611411781 354182 :SpaceDecEva!2fca62a2@47.202.98.162 QUIT :Quit: Connection closed < 1611412256 866211 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 QUIT :Remote host closed the connection < 1611412607 276467 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 JOIN :#esoteric < 1611412890 389854 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1611413828 596657 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Quit: WeeChat 2.3 < 1611413844 383365 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1611414242 135631 :Emerald!62dcfc03@98.220.252.3 JOIN :#esoteric < 1611414359 514114 :Emerald!62dcfc03@98.220.252.3 QUIT :Client Quit < 1611414467 136984 :Emerald!62dcfc03@98.220.252.3 JOIN :#esoteric < 1611414785 136104 :Emerald!62dcfc03@98.220.252.3 QUIT :Ping timeout: 248 seconds < 1611417518 265661 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca QUIT :Quit: ZNC 1.8.2 - https://znc.in < 1611417789 861721 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca JOIN :#esoteric < 1611418260 466744 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca QUIT :Quit: ZNC 1.8.2 - https://znc.in < 1611418284 854078 :naivesheep!~naiveshee@dhcp-108-168-36-20.cable.user.start.ca JOIN :#esoteric > 1611418449 507280 PRIVMSG #esoteric :14[[07Trivial14]]4 M10 02https://esolangs.org/w/index.php?diff=80218&oldid=80198 5* 03Hakerh400 5* (+1) 10 < 1611418669 282785 :myname!~myname@2001:41d0:1:766f::1 QUIT :Quit: WeeChat 2.9 < 1611418695 740140 :LKoen!~LKoen@57.174.9.109.rev.sfr.net QUIT :Remote host closed the connection < 1611418713 396436 :myname!~myname@2001:41d0:1:766f::1 JOIN :#esoteric > 1611418868 901974 PRIVMSG #esoteric :14[[07User:Ivancr7214]]4 10 02https://esolangs.org/w/index.php?diff=80219&oldid=53157 5* 03Ivancr72 5* (-208) 10Replaced content with "im cringe" < 1611419302 904046 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 QUIT :Remote host closed the connection < 1611419344 923551 :Deewiant!~deewiant@de1.ut.deewiant.iki.fi QUIT :Ping timeout: 256 seconds < 1611419363 254768 :Deewiant!~deewiant@de1.ut.deewiant.iki.fi JOIN :#esoteric > 1611419750 566129 PRIVMSG #esoteric :14[[07NyaScript14]]4 10 02https://esolangs.org/w/index.php?diff=80220&oldid=80058 5* 03ThatCookie 5* (+272) 10Added Variables < 1611420143 827916 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1611421016 677392 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1611421157 369413 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 265 seconds < 1611421157 689363 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life < 1611422322 327658 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 JOIN :#esoteric < 1611422375 349379 :LKoen!~LKoen@57.174.9.109.rev.sfr.net JOIN :#esoteric < 1611426288 883855 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Ping timeout: 260 seconds < 1611427363 725828 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru QUIT :Ping timeout: 264 seconds < 1611428918 521492 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1611429028 281072 :LKoen!~LKoen@57.174.9.109.rev.sfr.net QUIT :Remote host closed the connection < 1611429555 166339 :SpaceDecEva!48b975a0@072-185-117-160.res.spectrum.com JOIN :#esoteric < 1611429644 186011 :SpaceDecEva!48b975a0@072-185-117-160.res.spectrum.com QUIT :Client Quit < 1611429671 330456 :LKoen!~LKoen@57.174.9.109.rev.sfr.net JOIN :#esoteric < 1611430434 769519 :essays!~mrdata@186.125.218.148 JOIN :#esoteric < 1611430779 693295 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru JOIN :#esoteric < 1611431351 43821 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Ping timeout: 265 seconds < 1611431631 94364 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru QUIT :Ping timeout: 256 seconds > 1611432319 992202 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80221&oldid=80193 5* 03Digital Hunter 5* (+1054) 10/* 99 bottles of beer */ > 1611433871 278803 PRIVMSG #esoteric :14[[07Parse this sic/Numbers14]]4 N10 02https://esolangs.org/w/index.php?oldid=80222 5* 03Digital Hunter 5* (+5576) 10Hi, if it's not my place to create such a page let me know and I'll revert it! Or you can just delete it. I'm not sure quite what sort of category belongs here; the Underload page has Programming techniques but I don't feel that's appropriate here. > 1611434027 742770 PRIVMSG #esoteric :14[[07Parse this sic/Numbers14]]4 M10 02https://esolangs.org/w/index.php?diff=80223&oldid=80222 5* 03Digital Hunter 5* (+3) 10 > 1611434066 40206 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80224&oldid=80221 5* 03Digital Hunter 5* (+315) 10/* Numbers */ > 1611434091 59140 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80225&oldid=80224 5* 03Digital Hunter 5* (-38) 10/* Info to come */ The list of numbers has arrived! < 1611434677 623942 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric > 1611434846 794248 PRIVMSG #esoteric :14[[07Talk:NyaScript14]]4 N10 02https://esolangs.org/w/index.php?oldid=80226 5* 03PythonshellDebugwindow 5* (+347) 10/* Undocumented behaviour */ new section < 1611435973 922914 :mmmattyx!uid17782@gateway/web/irccloud.com/x-vztaiqdgaaagdemu JOIN :#esoteric < 1611435997 204694 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1611436421 612016 :diverger!~div@45.87.213.214 JOIN :#esoteric > 1611436873 366788 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 N10 02https://esolangs.org/w/index.php?oldid=80227 5* 03The-Ennemy 5* (+286) 10Created page with " ==About this tutorial== ==About Brainfuck== ==About asm2bf== ==Installing and "Hello World!"== ==Basic concepts== ==Conditionals== ==Memory model: taperam and stack==..." > 1611437452 485855 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80228&oldid=80227 5* 03The-Ennemy 5* (+391) 10/* About this tutorial */ > 1611438093 193213 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80229&oldid=80228 5* 03The-Ennemy 5* (+147) 10/* About this tutorial */ > 1611438269 269874 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80230&oldid=80229 5* 03The-Ennemy 5* (+2) 10/* Stack access */ > 1611438375 762027 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80231&oldid=80230 5* 03The-Ennemy 5* (+179) 10/* About this tutorial */ > 1611439947 136554 PRIVMSG #esoteric :14[[07Parse this sic14]]4 10 02https://esolangs.org/w/index.php?diff=80232&oldid=80225 5* 03Digital Hunter 5* (+0) 10/* Numbers */ my base conversion was bugged! Surprisingly not a PTS mistake, but one in understanding how concatenation works > 1611439992 19357 PRIVMSG #esoteric :14[[07Parse this sic14]]4 M10 02https://esolangs.org/w/index.php?diff=80233&oldid=80232 5* 03Digital Hunter 5* (+0) 10/* 99 bottles of beer */ updated to my realisation of the base conversion macro bug > 1611440362 243008 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80234&oldid=80231 5* 03The-Ennemy 5* (+1370) 10/* Installing and "Hello World!" */ > 1611440982 548828 PRIVMSG #esoteric :14[[07Deadfish14]]4 10 02https://esolangs.org/w/index.php?diff=80235&oldid=79871 5* 03Digital Hunter 5* (+638) 10/* Implementations */ Added an entry for Parse this sic. > 1611441039 380733 PRIVMSG #esoteric :14[[07Deadfish14]]4 M10 02https://esolangs.org/w/index.php?diff=80236&oldid=80235 5* 03Digital Hunter 5* (+27) 10/* Parse this sic */ > 1611441155 465369 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80237&oldid=80234 5* 03The-Ennemy 5* (+1017) 10/* Installing and "Hello World!" */ > 1611441589 810877 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80238&oldid=80237 5* 03The-Ennemy 5* (+304) 10/* Installing and "Hello World!" */ < 1611442484 330109 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 QUIT :Remote host closed the connection < 1611443284 175087 :LKoen!~LKoen@57.174.9.109.rev.sfr.net QUIT :Remote host closed the connection < 1611443820 846826 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca JOIN :#esoteric < 1611444255 520410 :LKoen!~LKoen@57.174.9.109.rev.sfr.net JOIN :#esoteric < 1611444437 144504 :LKoen!~LKoen@57.174.9.109.rev.sfr.net QUIT :Client Quit > 1611445705 921047 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80239&oldid=80238 5* 03The-Ennemy 5* (+1178) 10 < 1611445827 506763 :ArthurStrong!~ArthurStr@188.163.100.177 JOIN :#esoteric > 1611445923 37934 PRIVMSG #esoteric :14[[07User:The-Ennemy/asm2bf-tutorial14]]4 10 02https://esolangs.org/w/index.php?diff=80240&oldid=80239 5* 03The-Ennemy 5* (+189) 10/* Basic concepts */ < 1611446157 663715 :mmmattyx!uid17782@gateway/web/irccloud.com/x-vztaiqdgaaagdemu QUIT :Quit: Connection closed for inactivity