< 1610841684 486411 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com JOIN :#esoteric < 1610842847 819316 :LKoen!~LKoen@119.169.9.109.rev.sfr.net QUIT :Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.” < 1610842966 748180 :rain1!~My_user_n@unaffiliated/rain1 QUIT :Remote host closed the connection < 1610843005 928649 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1610843138 309198 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :it's just a small thing. it doesn't really matter, since there's an URL included. > 1610845947 721766 PRIVMSG #esoteric :14[[07Treehugger/Implementation14]]4 M10 02https://esolangs.org/w/index.php?diff=80048&oldid=62036 5* 03PythonshellDebugwindow 5* (+20) 10back > 1610845963 49433 PRIVMSG #esoteric :14[[07Treehugger14]]4 M10 02https://esolangs.org/w/index.php?diff=80049&oldid=78261 5* 03PythonshellDebugwindow 5* (+23) 10cat /* See Also */ < 1610847008 326404 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com QUIT :Quit: Leaving < 1610847691 35601 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Quit: sleep < 1610849379 475179 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`dowg wise < 1610849381 384542 :HackEso!~h@unaffiliated/fizzie/bot/hackeso PRIVMSG #esoteric :5585:2015-06-16 ` sed -i \'1N;s/\\n/ /\' wisdom/wise \ 5580:2015-06-15 ` echo It\\\'s neither clockwise nor counterclockwise nor otherwise. >> wisdom/wise \ 5579:2015-06-15 le/rn wise/Uninstalling software installed by the Wise Installation Wizard is unwise. < 1610849402 515744 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Man, I'd really like to delete that, but now it's not only my call. < 1610850428 469256 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Heh, recognized it, did you? I've always found it somehow charming. < 1610850433 572633 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Not sure exactly why. < 1610851827 632663 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1610852039 522668 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1610853167 919093 :mla!~mla@162.253.176.229 QUIT :Ping timeout: 246 seconds < 1610854214 69586 :BWBellairs!~bwbellair@hellomouse/dev/bwbellairs QUIT :Ping timeout: 256 seconds < 1610854216 559764 :BWBellairs[NNRF]!~bwbellair@hellomouse/dev/bwbellairs JOIN :#esoteric < 1610854222 2513 :heroux!sandroco@gateway/shell/insomnia247/x-zuajwwtmlecyqvvb QUIT :Ping timeout: 256 seconds < 1610854230 252973 :heroux!sandroco@gateway/shell/insomnia247/x-dfdxkregwegmvjgm JOIN :#esoteric < 1610854252 219718 :BWBellairs[NNRF]!~bwbellair@hellomouse/dev/bwbellairs NICK :BWBellairs < 1610855732 367734 :mla!~mla@162.253.176.229 JOIN :#esoteric < 1610855912 415893 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net PRIVMSG #esoteric :Maybe something involving widdershins < 1610857620 489984 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com JOIN :#esoteric < 1610860054 335849 :ArthurStrong!~ArthurStr@188.163.100.177 QUIT :Quit: leaving < 1610860405 548625 :MDude!~MDude@71.50.47.112 QUIT :Quit: Going offline, see ya! (www.adiirc.com) < 1610860668 131843 :wesleyac_!~wesleyac@bouncer.wesleyac.com NICK :wesleyac < 1610860907 962565 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1610861087 930262 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does anyone here have experience with using dynamic loaders on Linux x86-64 other than ld-linux.so? < 1610861113 637503 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm guessing not, but was idly wondering how difficult it is to use a custom dynamic loader (possibly along with a custom ABI) < 1610861485 679184 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :part of the reason I asked is that I'm getting fed up of all the overhead caused by the use of a fixed ABI, and think it might be interesting to write a programming language implementation where each function has its own ABI < 1610861553 878392 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. if function f calls function g, ideally you'd want f and g to use different registers for their arguments (and f's argument registers to be preserved by g) so that you wouldn't need to spill %edi < 1610861560 357928 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, %rdi < 1610861612 337049 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I have not have experience with using other dynamic loaders, but I do like the idea that each function can have its own ABI, and I had a similar idea than what you mention actually. < 1610861663 212503 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Although, my idea was to add a special calling convention into LLVM to denote this. < 1610861843 382683 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :However, if you are not intending to write a portable program (or if you are writing the program for a portable VM), then you can just write it by yourself anyways. < 1610861991 109315 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1610862006 638870 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although my idea was to get the compiler to work out a suitable ABI for each function, rather than doing it by hand < 1610862030 729429 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that way, the compiler input can be portable < 1610862043 325224 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but, interoperating with code that uses more standard ABIs will be difficult < 1610862072 277457 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could do it by generating wrapper functions that converted the ABI (also, it only matters if you want to pass a function pointer as an argument to a standard library function) < 1610862075 99252 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Yes, having the compiler work it out automatically is what was my idea with adding a special calling convention into LLVM. < 1610862091 957484 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(Although you cannot take the address of such functions) < 1610862120 917209 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I wanted to have a language where there was a partial order between calling conventions based on saving extra registers. < 1610862123 939793 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Have you read the LLVM documentation? < 1610862124 515792 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :another idea I had was to make code/function pointers 32 bits long, but data pointers 64 bits long < 1610862133 769095 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: I have read some of it, but not all of it < 1610862167 596915 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: yes, that would make sense < 1610862177 49214 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So you could use a function that doesn't clobber as many registers as an unknown function pointer, but at a specific call site you'd have more information. < 1610862181 725585 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although I think that if you're varying calling conventions, it makes sense to go all the way and vary which arguments are used, too < 1610862191 576994 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in order to save on renaming of registers < 1610862218 52974 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, another thing that I really really hate is the 16-byte stack alignment in the x86-64 ABI < 1610862220 53928 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You mean renaming as in generating code to shuffle them, not the thing the CPU does, I guess? < 1610862229 178556 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it is optimising for a rare case at the expense of the common case < 1610862244 681181 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: yes < 1610862259 268433 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Do modern CPUs care about alignment for anything? It's not clear to me whether they do. < 1610862271 383193 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it can have extreme performance impacts sometimes < 1610862283 435281 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When? < 1610862288 136385 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I know some instruction sets care about alignment and some don't < 1610862302 299250 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm currently debugging something that looks a lot like a performance bug in the processor, it's a very tight loop that speeds up if you add a memory read instruction to it < 1610862303 64479 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, x86 has some SIMD instructions with aligned/unaligned variants. < 1610862328 514554 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the reason I found this in the first place was that the loop was very alignment-sensitive, varying between about 6 and 11 seconds based on what alignment it was at < 1610862353 947511 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Why do you care about the dynamic loader for this? < 1610862359 862853 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(For example, in MMIX, all instructions and data are aligned; if you specify an address which is not aligned, the low bits of the address are ignored) < 1610862361 319313 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and I think that if it happened to hit a "bad" alignment, it had a similar effect to the memory read, making the loop go fast < 1610862366 357182 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Are you doing dynamic linking and also caring about these things this much? < 1610862380 899037 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :shachaf: Yes, I thought the same, how is it relevant to dynamic loading? < 1610862406 259703 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: mostly out of curiosity, I realised that the existing dynamic linker wouldn't like a system where the calling conventions were different; also, because I'm thinking about what would be required to make drastic changes to a process's memory layout < 1610862408 597329 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :I should think that automatically making up their own calling conventions will not work at all if the function is to be called dynamically. < 1610862428 719197 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also because replacing the dynamic linker seems like the easiest way to control what `exec` does to a program < 1610862447 853142 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, I'd probably sooner disable the dynamic linker and statically link the programs that matter. < 1610862478 975982 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :is it even possible to have a program that doesn't use the dynamic linker at all? if so, what controls its memory layout? < 1610862492 467744 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :presumably the kernel has an appropriate loader available < 1610862501 806273 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The kernel loads it according to ELF directives. < 1610862515 11751 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But it can do whatever it wants after that. < 1610862527 718177 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :(Although, it should work if only the same program that defines the function calls it, then it will work without dynamic calling, even if other functions are called dynamically I would think, although entries into your program also need to use standard calling conventions, even if the other functions only used internally can use your own kinds) < 1610862608 418608 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm mildly irritated at modern gcc putting `endbr64` instructions at the start of every externallly function, just in case someone decides to take their address < 1610862638 146881 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which removes half the security value of that, and also blows up the binary size and instruction decode pipeline < 1610862650 881940 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, ideally not many functions are extern. < 1610862666 367282 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :What does "endbr64" instruction mean? < 1610862684 825074 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It means that indirect branches to that address are allowed. < 1610862697 652263 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you enable a security option then branches to any other instruction will trap. < 1610862697 846346 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's a NOP, but Intel is developing processors which don't allow indirect branches/calls to anything other than an endbr64 instruciton < 1610862712 615443 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or maybe that option isn't available yet, I don't know. < 1610862724 6192 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it doesn't exist on my processor, at least < 1610862762 145866 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, the security gain of this seems to be largest if endbr64 instructions are confined to locations where they're actually necessary (it's rare to take the address of a function) < 1610862785 97351 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But if the function is extern and you're doing separate compilation, there's no way to know. < 1610862798 383659 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Unless you add an annotation for a function you're allowed to take the address of. < 1610862802 659052 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1610862813 906410 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm disappointed that C wasn't created with such an annotation < 1610862822 397166 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, it has "static". < 1610862829 48250 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Mostly I try to put as much as possible into a single translation unit, which also lets you make things static. < 1610862842 491621 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But there are many annotations that we wish C had. < 1610862844 825246 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Maybe they should allow removing the "endbr64" instruction by writing "register" in the definition of the function, since the "register" command in C means that you are not allowed to take the address of it. < 1610862861 330806 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :zzo38: Aha, that's cute. < 1610862881 526287 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :amusingly, I had exactly the same idea < 1610862882 246665 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1610862902 506134 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: the problem with large translation units is that it increases the amount you have to recompile upon making a change to the program < 1610862913 425483 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Of course that won't work with dynamic linking, but if it is used with static linking then it would work. < 1610862924 834961 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also, you need sufficiently many translation units to keep all the CPU cores busy in a parallel build < 1610862939 168728 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, but compilers should preferably be very fast. < 1610862949 985862 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: it could work with dynamic linking; it's very common nowadays to use a configuration in which most functions are marked as not dynamically linkable < 1610862967 432597 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :ais523: O, OK. < 1610863009 861592 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think every dynamic library I've worked on in the last >10 years has used a configuration in which functions are not dynamically linkable as default, but a macro is available to specify that a specific function is dynamically linkable < 1610863036 219652 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Dynamic linking should be treated as a rare, special-case thing anyway. < 1610863039 523455 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that way, you can write the library in multiple translation units, but avoid polluting the namespace of a user of your library with your internal non-`static` functions < 1610863040 479243 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Most libraries should be static. < 1610863077 965105 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I can see the argument for a library that's shared between most of the processes on the system being dynamically linked by them, in order to save physical memory < 1610863085 526970 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1610863105 22783 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(although this requires that the various copies of it mapped into the various processes that use it are byte-for-byte identical) < 1610863113 833641 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think that argument is not that relevant nowadays. < 1610863165 828537 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But the few libraries that are really shared among all processes probably do count as special-case, anyway. < 1610863168 282922 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the other advantage of dynamic libraries is that you can update them without recompiling the programs that depend on them < 1610863189 983014 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, libm is still separate from libc for some reason, isn't it? < 1610863192 262921 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :as is libpthread < 1610863226 310181 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :those three are universal enough that merging them would make sense < 1610863324 804550 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think that advantage is weak and the disadvantages outweigh it. < 1610863346 831771 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But you could also allow static libraries to be relinked in the same executable. < 1610863433 226095 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Agner Fog's https://forwardcom.info/ works that way, I think. < 1610863498 542623 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Many programs don't use threads < 1610863529 303281 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even so, the standard library normally has to at least be *aware* of threads < 1610863544 843219 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to implement things like `errno` and even `malloc` < 1610863579 351532 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :O, yes, OK. < 1610863581 383148 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also I discovered that writing an async-signal-safe `malloc` is harder than it seems < 1610863603 542515 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you don't have software transactional memory, you need some way to do an atomic double store of a pointer and the current thread ID < 1610863612 762899 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(luckily, doing it to consecutive addresses is sufficient) < 1610868061 505581 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Ping timeout: 246 seconds < 1610870626 678056 :ais523!~ais523@unaffiliated/ais523 QUIT :Read error: Connection reset by peer < 1610870641 283286 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1610871891 31245 :rain1!~My_user_n@unaffiliated/rain1 JOIN :#esoteric > 1610872446 969261 PRIVMSG #esoteric :14[[07Special:Log/newusers14]]4 create10 02 5* 03ThatCookie 5* 10New user account > 1610872702 580755 PRIVMSG #esoteric :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=80050&oldid=80044 5* 03ThatCookie 5* (+83) 10I introduced myself > 1610874582 240596 PRIVMSG #esoteric :14[[07NyaScript14]]4 N10 02https://esolangs.org/w/index.php?oldid=80051 5* 03ThatCookie 5* (+1658) 10Made NyaScript's page > 1610874855 541560 PRIVMSG #esoteric :14[[07NyaScript14]]4 10 02https://esolangs.org/w/index.php?diff=80052&oldid=80051 5* 03ThatCookie 5* (+53) 10 > 1610874944 660939 PRIVMSG #esoteric :14[[07Language list14]]4 10 02https://esolangs.org/w/index.php?diff=80053&oldid=80030 5* 03ThatCookie 5* (+16) 10Added NyaScript < 1610875140 483944 :delta23!~deltaepsi@d179-68-39-184.evv.wideopenwest.com QUIT :Quit: Leaving < 1610875707 302450 :user24!~user24@2a02:810a:1440:7304:24af:acaf:50b7:d466 JOIN :#esoteric < 1610876659 57165 :ais523!~ais523@unaffiliated/ais523 QUIT :Read error: Connection reset by peer < 1610876672 892469 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1610877182 787225 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1610878590 982034 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" ... I'm getting fed up of all the overhead caused by the use of a fixed ABI" => the usual solution to that is that the optimizer can use a different ABI for functions within a compilation unit, while keeping the usual ABI between compilation units. And when you want such optimization between compilation units, then you artificially export some part of the functions to the calling compilation < 1610878597 243183 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :units using C99 inline functions, C++ templates, or rust inline functions. < 1610878677 903607 :LKoen!~LKoen@119.169.9.109.rev.sfr.net JOIN :#esoteric < 1610878783 459940 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" Do modern CPUs care about alignment for anything?" => yes in the sense of performance. the only common case when it causes slowdowns is when you access data that crosses the boundary of 64-bit pages, but if you don't align your data then you will have such cases. also some SSE instructions (but not AVX ones) do require 16 byte alignment and fault if they don't get it. < 1610878820 503331 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" Yes, x86 has some SIMD instructions with aligned/unaligned variants." => that doesn't apply to modern CPUs though, those instructions are treated the same now < 1610878930 47019 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" is it even possible to have a program that doesn't use the dynamic linker at all?" => in theory yes; in practice there are parts of libc that you can't use without, and it's very hard to get rid of libc in big practical programs in practice, the whole infrastructure is built around it. < 1610878966 936209 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :the kernel mostly supports that because it has to load the dynamic linker somehow, and loading that is the same ELF loading process as loading a program without a dynamic linker. < 1610879115 956433 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :“ Maybe they should allow removing the "endbr64" instruction by writing "register" in the definition of the function” => I think that might conflict with some modern C++ modules nonsense thing that reuses the register keyword, I'm not sure < 1610879129 164086 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :you'd have to check before you use it < 1610879189 417228 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :b_jonas: Yes, crossing page boundaries (or cache line boundaries) certainly can have real effects. I meant things like unaligned loads within a cache line. < 1610879259 396403 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" I can see the argument for a library that's shared between most of the processes on the system being dynamically linked by them, in order to save physical memory / (although this requires that the various copies of it mapped into the various processes that use it are byte-for-byte identical)" => that is what actually happens these days, at least on x86_64 which has PC-relative instructions and < 1610879265 404827 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :enough registers and so supports efficient position-independent code and can load the same code segments to different addresses in different processes effectively. < 1610879270 664940 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :(I think it still happens on x86, but with more overhead.) < 1610879321 735959 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" I think that argument is not that relevant nowadays." => I think it's still relevant, at least in some workloads like browsers or JVM or similar that have dozens of threads or processes with the same huge set of libraries in them < 1610879361 604891 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :" hmm, libm is still separate from libc for some reason, isn't it?" => I think on x86_64 it's not, and libm is an empty library that's present only for compatibility there < 1610879412 970221 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :libpthread might be separate, I'm not sure, but parts of libc only work if you tell it at compile time with a macro that the process uses pthreads, which the shorthand -pthreads option to gcc does. < 1610879449 112408 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :or maybe libm is empty on later versions of libc and this has nothing to do with x86_64? I don't know < 1610879521 676218 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :shachaf: modern cpus don't currently mind unaligned loads or stores within a cache line, except for those SSE instructions that can raise a fault (depending on some process-global mode bit I think) < 1610879597 598598 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :plus there's some magic about alignment modulo 16 bytes that matters for code performance, namely for the decoder and for some of the jump prediction < 1610879610 741195 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :but I'm not sure of the details < 1610879761 869582 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :I for one think it's generally a good idea to keep every data naturally aligned, except in those cases when you really can't because you need shifts such as for pixel buffer operations, and in those cases try to keep writes aligned. it's a guideline that makes it easy to avoid access crossing cache line boundaries, and it's generally easier to keep in a complicated program across functions than directly < 1610879767 874518 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :figuring out what crosses page boundaries when your data may be allocated by some other function. < 1610879857 405869 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :as for ais523's original problem, the 16 byte vs 8 byte stack alignment, I'm not quite sure < 1610880417 589472 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1610882076 68636 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :can it cause problems (with any compiler or tools) to have C or C++ header files that only have comments, nothing else? < 1610882108 890480 :b_jonas!~a@catv-176-63-12-89.catv.broadband.hu PRIVMSG #esoteric :I don't think it can, but if it can, then I'll include some dummy declaration. > 1610882956 220588 PRIVMSG #esoteric :14[[07Hello world program in esoteric languages14]]4 M10 02https://esolangs.org/w/index.php?diff=80054&oldid=79262 5* 03Supyovalk 5* (+30) 10added compute < 1610883084 129983 :spruit11!~unknown@86-82-44-193.fixed.kpn.net QUIT :Ping timeout: 272 seconds < 1610886646 482293 :spruit11!~unknown@86-82-44-193.fixed.kpn.net JOIN :#esoteric < 1610886879 584484 :user24!~user24@2a02:810a:1440:7304:24af:acaf:50b7:d466 QUIT :Quit: Leaving < 1610890228 2671 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 256 seconds < 1610890628 596085 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1610891693 342199 :gitlogger!~gitlogger@135.181.161.188 QUIT :Remote host closed the connection < 1610891768 508795 :kspalaiologos!~palaiolog@176.221.122.174 JOIN :#esoteric < 1610891799 504376 :gitlogger!~gitlogger@135.181.161.188 JOIN :#esoteric < 1610892068 265671 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 JOIN :#esoteric < 1610892995 125974 :LKoen_!~LKoen@119.169.9.109.rev.sfr.net JOIN :#esoteric < 1610893151 931549 :LKoen!~LKoen@119.169.9.109.rev.sfr.net QUIT :Ping timeout: 246 seconds < 1610893569 959059 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1610893970 924734 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net QUIT :Ping timeout: 246 seconds < 1610894403 932623 :privateger!~privatege@2a00:6020:11c3:d600:1dba:39b3:131b:1024 JOIN :#esoteric < 1610895153 959289 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru JOIN :#esoteric < 1610895800 130803 :privateger!~privatege@2a00:6020:11c3:d600:1dba:39b3:131b:1024 QUIT :Read error: Connection reset by peer < 1610895865 915512 :privateger!~privatege@2a00:6020:11c3:d600:1dba:39b3:131b:1024 JOIN :#esoteric < 1610895883 592260 :privateger!~privatege@2a00:6020:11c3:d600:1dba:39b3:131b:1024 QUIT :Client Quit < 1610896041 965912 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Ping timeout: 256 seconds < 1610896832 478200 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1610897191 300854 :admins!~admin@unaffiliated/zeroed NICK :zeroed < 1610897915 266356 :mmmattyx!uid17782@gateway/web/irccloud.com/x-qvjkocemxgyxrpwr JOIN :#esoteric < 1610897939 601533 :TheLie!~TheLie@2a02:8106:215:3300:e7ad:5ab7:4ea0:e177 QUIT :Remote host closed the connection < 1610899512 745011 :LKoen!~LKoen@119.169.9.109.rev.sfr.net JOIN :#esoteric < 1610899512 745063 :arseniiv_!~arseniiv@95.105.12.104.dynamic.ufanet.ru JOIN :#esoteric < 1610899513 115563 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Ping timeout: 264 seconds < 1610899513 333475 :arseniiv!~arseniiv@95.105.12.104.dynamic.ufanet.ru QUIT :Ping timeout: 256 seconds < 1610899513 333586 :LKoen_!~LKoen@119.169.9.109.rev.sfr.net QUIT :Ping timeout: 256 seconds < 1610902064 233095 :MDude!~MDude@71.50.47.112 JOIN :#esoteric < 1610902202 877726 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric > 1610902246 578998 PRIVMSG #esoteric :14[[07Special:Log/newusers14]]4 create10 02 5* 03Jb 5* 10New user account < 1610902281 332846 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1610902391 268861 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 265 seconds > 1610902523 697922 PRIVMSG #esoteric :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=80055&oldid=80050 5* 03Jb 5* (+70) 10 > 1610902531 368744 PRIVMSG #esoteric :14[[07Blub14]]4 M10 02https://esolangs.org/w/index.php?diff=80056&oldid=77815 5* 03Jb 5* (+1374) 10added loop example < 1610902550 258937 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life < 1610905938 485626 :ArthurStrong!~ArthurStr@188.163.100.177 JOIN :#esoteric < 1610906853 881611 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com QUIT :Ping timeout: 260 seconds < 1610907523 49502 :copumpkin!~copumpkin@unaffiliated/copumpkin QUIT :Quit: Hmmm < 1610911070 518797 :ubq323!~ubq323@host86-165-21-46.range86-165.btcentralplus.com JOIN :#esoteric < 1610911719 774231 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1610913464 794752 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1610914841 395988 :Dietrich[m]1!ph-dietric@gateway/shell/matrix.org/x-xbenvulaxoinrgmn JOIN :#esoteric < 1610914870 665532 :Dietrich[m]1!ph-dietric@gateway/shell/matrix.org/x-xbenvulaxoinrgmn PART :#esoteric < 1610915657 842804 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Quit: ... < 1610915738 480635 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1610916167 991324 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 246 seconds < 1610916211 713318 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1610916382 10478 :sprock!~sprocklem@unaffiliated/sprocklem QUIT :Quit: ... < 1610916842 543477 :iovoid!iovoid@hellomouse/dev/iovoid QUIT :Ping timeout: 264 seconds < 1610916925 912965 :iovoid!iovoid@hellomouse/dev/iovoid JOIN :#esoteric < 1610918180 482250 :sprock!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1610918755 244988 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Glulx has malloc, free, and sbrk, but not realloc. < 1610919264 639076 :rain1!~My_user_n@unaffiliated/rain1 PRIVMSG #esoteric :cool! < 1610919630 108589 :kspalaiologos!~palaiolog@176.221.122.174 QUIT :Quit: Leaving > 1610920013 688889 PRIVMSG #esoteric :14[[07NyaScript14]]4 M10 02https://esolangs.org/w/index.php?diff=80057&oldid=80052 5* 03PythonshellDebugwindow 5* (+369) 10/* Hello, World! */ Cats, compiler > 1610920044 195919 PRIVMSG #esoteric :14[[07NyaScript14]]4 M10 02https://esolangs.org/w/index.php?diff=80058&oldid=80057 5* 03PythonshellDebugwindow 5* (-1) 10Fix link < 1610920268 241528 :zzo38!~zzo38@host-24-207-14-22.public.eastlink.ca PRIVMSG #esoteric :Do you know if GCC or LLVM can target any instruction set where the stack has a separate address space which you cannot access? > 1610920753 446640 PRIVMSG #esoteric :14[[07Special:Log/newusers14]]4 create10 02 5* 03Zero player rodent 5* 10New user account > 1610921169 274112 PRIVMSG #esoteric :14[[07Esolang:Introduce yourself14]]4 10 02https://esolangs.org/w/index.php?diff=80059&oldid=80055 5* 03Zero player rodent 5* (+243) 10/* Introductions */ < 1610921791 256197 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar QUIT :*.net *.split < 1610921899 970562 :mmmattyx!uid17782@gateway/web/irccloud.com/x-qvjkocemxgyxrpwr QUIT :Quit: Connection closed for inactivity < 1610922162 853441 :xelxebar!~xelxebar@gateway/tor-sasl/xelxebar JOIN :#esoteric < 1610922789 878859 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1610923116 809816 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1610924645 971238 :LKoen!~LKoen@119.169.9.109.rev.sfr.net QUIT :Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.” < 1610926383 769394 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net QUIT :Read error: Connection reset by peer < 1610926513 894182 :Sgeo!~Sgeo@ool-18b98aa4.dyn.optonline.net JOIN :#esoteric < 1610926820 959502 :Arcorann!~awych@159-196-65-46.9fc441.mel.nbn.aussiebb.net JOIN :#esoteric < 1610927460 316370 :rain1!~My_user_n@unaffiliated/rain1 QUIT :Remote host closed the connection