00:01:24 -!- delta23 has joined.
00:20:47 -!- LKoen has 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.”).
00:22:46 -!- rain1 has quit (Remote host closed the connection).
00:23:25 -!- Arcorann has joined.
00:25:38 <b_jonas> it's just a small thing. it doesn't really matter, since there's an URL included.
01:12:27 <esowiki> [[Treehugger/Implementation]] M https://esolangs.org/w/index.php?diff=80048&oldid=62036 * PythonshellDebugwindow * (+20) back
01:12:43 <esowiki> [[Treehugger]] M https://esolangs.org/w/index.php?diff=80049&oldid=78261 * PythonshellDebugwindow * (+23) cat /* See Also */
01:30:08 -!- delta23 has quit (Quit: Leaving).
01:41:31 -!- ubq323 has quit (Quit: sleep).
02:09:41 <HackEso> 5585:2015-06-16 <oerjän> ` sed -i \'1N;s/\\n/ /\' wisdom/wise \ 5580:2015-06-15 <int-̈e> ` echo It\\\'s neither clockwise nor counterclockwise nor otherwise. >> wisdom/wise \ 5579:2015-06-15 <shachäf> le/rn wise/Uninstalling software installed by the Wise Installation Wizard is unwise.
02:10:02 <shachaf> Man, I'd really like to delete that, but now it's not only my call.
02:27:08 <fizzie> Heh, recognized it, did you? I've always found it somehow charming.
02:50:27 -!- Sgeo has quit (Read error: Connection reset by peer).
02:53:59 -!- Sgeo has joined.
03:12:47 -!- mla has quit (Ping timeout: 246 seconds).
03:30:14 -!- BWBellairs has quit (Ping timeout: 256 seconds).
03:30:16 -!- BWBellairs[NNRF] has joined.
03:30:22 -!- heroux has quit (Ping timeout: 256 seconds).
03:30:30 -!- heroux has joined.
03:30:52 -!- BWBellairs[NNRF] has changed nick to BWBellairs.
03:55:32 -!- mla has joined.
03:58:32 <Arcorann> Maybe something involving widdershins
04:27:00 -!- delta23 has joined.
05:07:34 -!- ArthurStrong has quit (Quit: leaving).
05:13:25 -!- MDude has quit (Quit: Going offline, see ya! (www.adiirc.com)).
05:17:48 -!- wesleyac_ has changed nick to wesleyac.
05:21:47 -!- ais523 has joined.
05:24:47 <ais523> does anyone here have experience with using dynamic loaders on Linux x86-64 other than ld-linux.so?
05:25:13 <ais523> I'm guessing not, but was idly wondering how difficult it is to use a custom dynamic loader (possibly along with a custom ABI)
05:31:25 <ais523> 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
05:32:33 <ais523> 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
05:33:32 <zzo38> 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.
05:34:23 <zzo38> Although, my idea was to add a special calling convention into LLVM to denote this.
05:37:23 <zzo38> 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.
05:40:06 <ais523> although my idea was to get the compiler to work out a suitable ABI for each function, rather than doing it by hand
05:40:30 <ais523> that way, the compiler input can be portable
05:40:43 <ais523> but, interoperating with code that uses more standard ABIs will be difficult
05:41:12 <ais523> 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)
05:41:15 <zzo38> Yes, having the compiler work it out automatically is what was my idea with adding a special calling convention into LLVM.
05:41:31 <zzo38> (Although you cannot take the address of such functions)
05:42:00 <shachaf> ais523: I wanted to have a language where there was a partial order between calling conventions based on saving extra registers.
05:42:03 <zzo38> Have you read the LLVM documentation?
05:42:04 <ais523> another idea I had was to make code/function pointers 32 bits long, but data pointers 64 bits long
05:42:13 <ais523> zzo38: I have read some of it, but not all of it
05:42:47 <ais523> shachaf: yes, that would make sense
05:42:57 <shachaf> 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.
05:43:01 <ais523> 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
05:43:11 <ais523> in order to save on renaming of registers
05:43:38 <ais523> oh, another thing that I really really hate is the 16-byte stack alignment in the x86-64 ABI
05:43:40 <shachaf> You mean renaming as in generating code to shuffle them, not the thing the CPU does, I guess?
05:43:49 <ais523> it is optimising for a rare case at the expense of the common case
05:44:19 <shachaf> Do modern CPUs care about alignment for anything? It's not clear to me whether they do.
05:44:31 <ais523> it can have extreme performance impacts sometimes
05:44:48 <zzo38> I know some instruction sets care about alignment and some don't
05:45:02 <ais523> 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
05:45:03 <shachaf> Yes, x86 has some SIMD instructions with aligned/unaligned variants.
05:45:28 <ais523> 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
05:45:53 <shachaf> Why do you care about the dynamic loader for this?
05:45:59 <zzo38> (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)
05:46:01 <ais523> 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
05:46:06 <shachaf> Are you doing dynamic linking and also caring about these things this much?
05:46:20 <zzo38> shachaf: Yes, I thought the same, how is it relevant to dynamic loading?
05:46:46 <ais523> 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
05:46:48 <zzo38> I should think that automatically making up their own calling conventions will not work at all if the function is to be called dynamically.
05:47:08 <ais523> also because replacing the dynamic linker seems like the easiest way to control what `exec` does to a program
05:47:27 <shachaf> Well, I'd probably sooner disable the dynamic linker and statically link the programs that matter.
05:47:58 <ais523> is it even possible to have a program that doesn't use the dynamic linker at all? if so, what controls its memory layout?
05:48:12 <ais523> presumably the kernel has an appropriate loader available
05:48:21 <shachaf> The kernel loads it according to ELF directives.
05:48:35 <shachaf> But it can do whatever it wants after that.
05:48:47 <zzo38> (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)
05:50:08 <ais523> 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
05:50:38 <ais523> which removes half the security value of that, and also blows up the binary size and instruction decode pipeline
05:50:50 <shachaf> Well, ideally not many functions are extern.
05:51:06 <zzo38> What does "endbr64" instruction mean?
05:51:24 <shachaf> It means that indirect branches to that address are allowed.
05:51:37 <shachaf> If you enable a security option then branches to any other instruction will trap.
05:51:37 <ais523> it's a NOP, but Intel is developing processors which don't allow indirect branches/calls to anything other than an endbr64 instruciton
05:51:52 <shachaf> Or maybe that option isn't available yet, I don't know.
05:52:04 <ais523> it doesn't exist on my processor, at least
05:52:42 <ais523> 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)
05:53:05 <shachaf> But if the function is extern and you're doing separate compilation, there's no way to know.
05:53:18 <shachaf> Unless you add an annotation for a function you're allowed to take the address of.
05:53:33 <ais523> I'm disappointed that C wasn't created with such an annotation
05:53:49 <shachaf> Mostly I try to put as much as possible into a single translation unit, which also lets you make things static.
05:54:02 <shachaf> But there are many annotations that we wish C had.
05:54:04 <zzo38> 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.
05:54:41 <ais523> amusingly, I had exactly the same idea
05:54:42 -!- Sgeo has quit (Read error: Connection reset by peer).
05:55:02 <ais523> shachaf: the problem with large translation units is that it increases the amount you have to recompile upon making a change to the program
05:55:13 <zzo38> Of course that won't work with dynamic linking, but if it is used with static linking then it would work.
05:55:24 <ais523> also, you need sufficiently many translation units to keep all the CPU cores busy in a parallel build
05:55:39 <shachaf> Yes, but compilers should preferably be very fast.
05:55:49 <ais523> 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
05:56:49 <ais523> 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
05:57:16 <shachaf> Dynamic linking should be treated as a rare, special-case thing anyway.
05:57:19 <ais523> 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
05:57:20 <shachaf> Most libraries should be static.
05:57:57 <ais523> 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
05:58:05 -!- Sgeo has joined.
05:58:25 <ais523> (although this requires that the various copies of it mapped into the various processes that use it are byte-for-byte identical)
05:58:33 <shachaf> I think that argument is not that relevant nowadays.
05:59:25 <shachaf> But the few libraries that are really shared among all processes probably do count as special-case, anyway.
05:59:28 <ais523> the other advantage of dynamic libraries is that you can update them without recompiling the programs that depend on them
05:59:49 <ais523> hmm, libm is still separate from libc for some reason, isn't it?
06:00:26 <ais523> those three are universal enough that merging them would make sense
06:02:04 <shachaf> I think that advantage is weak and the disadvantages outweigh it.
06:02:26 <shachaf> But you could also allow static libraries to be relinked in the same executable.
06:03:53 <shachaf> Agner Fog's https://forwardcom.info/ works that way, I think.
06:04:58 <zzo38> Many programs don't use threads
06:05:29 <ais523> even so, the standard library normally has to at least be *aware* of threads
06:05:44 <ais523> to implement things like `errno` and even `malloc`
06:06:21 <ais523> also I discovered that writing an async-signal-safe `malloc` is harder than it seems
06:06:43 <ais523> 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
06:06:52 <ais523> (luckily, doing it to consecutive addresses is sufficient)
07:21:01 -!- sprock has quit (Ping timeout: 246 seconds).
08:03:46 -!- ais523 has quit (Read error: Connection reset by peer).
08:04:01 -!- ais523 has joined.
08:24:51 -!- rain1 has joined.
08:34:06 <esowiki> [[Special:Log/newusers]] create * ThatCookie * New user account
08:38:22 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=80050&oldid=80044 * ThatCookie * (+83) I introduced myself
09:09:42 <esowiki> [[NyaScript]] N https://esolangs.org/w/index.php?oldid=80051 * ThatCookie * (+1658) Made NyaScript's page
09:14:15 <esowiki> [[NyaScript]] https://esolangs.org/w/index.php?diff=80052&oldid=80051 * ThatCookie * (+53)
09:15:44 <esowiki> [[Language list]] https://esolangs.org/w/index.php?diff=80053&oldid=80030 * ThatCookie * (+16) Added NyaScript
09:19:00 -!- delta23 has quit (Quit: Leaving).
09:28:27 -!- user24 has joined.
09:44:19 -!- ais523 has quit (Read error: Connection reset by peer).
09:44:32 -!- ais523 has joined.
09:53:02 -!- ais523 has quit (Quit: quit).
10:16:30 <b_jonas> "<ais523> ... 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
10:16:37 <b_jonas> units using C99 inline functions, C++ templates, or rust inline functions.
10:17:57 -!- LKoen has joined.
10:19:43 <b_jonas> "<shachaf> 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.
10:20:20 <b_jonas> "<shachaf> 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
10:22:10 <b_jonas> "<ais523> 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.
10:22:46 <b_jonas> 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.
10:25:15 <b_jonas> “<zzo38> 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
10:25:29 <b_jonas> you'd have to check before you use it
10:26:29 <shachaf> 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.
10:27:39 <b_jonas> "<ais523> 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
10:27:45 <b_jonas> enough registers and so supports efficient position-independent code and can load the same code segments to different addresses in different processes effectively.
10:27:50 <b_jonas> (I think it still happens on x86, but with more overhead.)
10:28:41 <b_jonas> "<shachaf> 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
10:29:21 <b_jonas> "<ais523> 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
10:30:12 <b_jonas> 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.
10:30:49 <b_jonas> or maybe libm is empty on later versions of libc and this has nothing to do with x86_64? I don't know
10:32:01 <b_jonas> 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)
10:33:17 <b_jonas> 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
10:33:30 <b_jonas> but I'm not sure of the details
10:36:01 <b_jonas> 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
10:36:07 <b_jonas> figuring out what crosses page boundaries when your data may be allocated by some other function.
10:37:37 <b_jonas> as for ais523's original problem, the 16 byte vs 8 byte stack alignment, I'm not quite sure
10:46:57 -!- Sgeo has quit (Read error: Connection reset by peer).
11:14:36 <b_jonas> can it cause problems (with any compiler or tools) to have C or C++ header files that only have comments, nothing else?
11:15:08 <b_jonas> I don't think it can, but if it can, then I'll include some dummy declaration.
11:29:16 <esowiki> [[Hello world program in esoteric languages]] M https://esolangs.org/w/index.php?diff=80054&oldid=79262 * Supyovalk * (+30) added compute
11:31:24 -!- spruit11 has quit (Ping timeout: 272 seconds).
12:30:46 -!- spruit11 has joined.
12:34:39 -!- user24 has quit (Quit: Leaving).
13:30:28 -!- Lord_of_Life has quit (Ping timeout: 256 seconds).
13:37:08 -!- Lord_of_Life has joined.
13:54:53 -!- gitlogger has quit (Remote host closed the connection).
13:56:08 -!- kspalaiologos has joined.
13:56:39 -!- gitlogger has joined.
14:01:08 -!- TheLie has joined.
14:16:35 -!- LKoen_ has joined.
14:19:11 -!- LKoen has quit (Ping timeout: 246 seconds).
14:26:09 -!- ubq323 has joined.
14:32:50 -!- Arcorann has quit (Ping timeout: 246 seconds).
14:40:03 -!- privateger has joined.
14:52:33 -!- arseniiv has joined.
15:03:20 -!- privateger has quit (Read error: Connection reset by peer).
15:04:25 -!- privateger has joined.
15:04:43 -!- privateger has quit (Client Quit).
15:07:21 -!- ubq323 has quit (Ping timeout: 256 seconds).
15:20:32 -!- ubq323 has joined.
15:26:31 -!- admins has changed nick to zeroed.
15:38:35 -!- mmmattyx has joined.
15:38:59 -!- TheLie has quit (Remote host closed the connection).
16:05:12 -!- LKoen has joined.
16:05:12 -!- arseniiv_ has joined.
16:05:13 -!- ubq323 has quit (Ping timeout: 264 seconds).
16:05:13 -!- arseniiv has quit (Ping timeout: 256 seconds).
16:05:13 -!- LKoen_ has quit (Ping timeout: 256 seconds).
16:47:44 -!- MDude has joined.
16:50:02 -!- ubq323 has joined.
16:50:46 <esowiki> [[Special:Log/newusers]] create * Jb * New user account
16:51:21 -!- Lord_of_Life_ has joined.
16:53:11 -!- Lord_of_Life has quit (Ping timeout: 265 seconds).
16:55:23 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=80055&oldid=80050 * Jb * (+70)
16:55:31 <esowiki> [[Blub]] M https://esolangs.org/w/index.php?diff=80056&oldid=77815 * Jb * (+1374) added loop example
16:55:50 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
17:52:18 -!- ArthurStrong has joined.
18:07:33 -!- ubq323 has quit (Ping timeout: 260 seconds).
18:18:43 -!- copumpkin has quit (Quit: Hmmm).
19:17:50 -!- ubq323 has joined.
19:28:39 -!- sprock has joined.
19:57:44 -!- Sgeo has joined.
20:20:41 -!- Dietrich[m]1 has joined.
20:21:10 -!- Dietrich[m]1 has left.
20:34:17 -!- sprock has quit (Quit: ...).
20:35:38 -!- sprock has joined.
20:42:47 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
20:43:31 -!- Lord_of_Life has joined.
20:46:22 -!- sprock has quit (Quit: ...).
20:54:02 -!- iovoid has quit (Ping timeout: 264 seconds).
20:55:25 -!- iovoid has joined.
21:16:20 -!- sprock has joined.
21:25:55 <zzo38> Glulx has malloc, free, and sbrk, but not realloc.
21:40:30 -!- kspalaiologos has quit (Quit: Leaving).
21:46:53 <esowiki> [[NyaScript]] M https://esolangs.org/w/index.php?diff=80057&oldid=80052 * PythonshellDebugwindow * (+369) /* Hello, World! */ Cats, compiler
21:47:24 <esowiki> [[NyaScript]] M https://esolangs.org/w/index.php?diff=80058&oldid=80057 * PythonshellDebugwindow * (-1) Fix link
21:51:08 <zzo38> Do you know if GCC or LLVM can target any instruction set where the stack has a separate address space which you cannot access?
21:59:13 <esowiki> [[Special:Log/newusers]] create * Zero player rodent * New user account
22:06:09 <esowiki> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=80059&oldid=80055 * Zero player rodent * (+243) /* Introductions */
22:16:31 -!- xelxebar has quit (*.net *.split).
22:18:19 -!- mmmattyx has quit (Quit: Connection closed for inactivity).
22:22:42 -!- xelxebar has joined.
22:33:09 -!- Sgeo has quit (Read error: Connection reset by peer).
22:38:36 -!- Sgeo has joined.
23:04:05 -!- LKoen has 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.”).
23:33:03 -!- Sgeo has quit (Read error: Connection reset by peer).
23:35:13 -!- Sgeo has joined.
23:40:20 -!- Arcorann has joined.
23:51:00 -!- rain1 has quit (Remote host closed the connection).