00:14:40 -!- sftp has quit (Read error: Connection reset by peer).
00:18:01 -!- sftp has joined.
00:18:01 -!- sftp has changed hostmask to ~sftp@user/sftp.
00:26:52 <esolangs> [[GTPS]] N https://esolangs.org/w/index.php?oldid=172431 * A() * (+185) Created page with "[[GTPS| Group Theory Programming System]] is a programming language made by [[User: A()]] with the intention of being based on [https://en.wikipedia.org/wiki/Group_theory| Group theory]"
00:32:40 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172432&oldid=172431 * A() * (+70)
01:04:37 <ais523> I remember noticing before that Z-order is basically just the INTERCAL mingle operation
01:04:52 <esolangs> [[User:Aadenboy/Countable]] M https://esolangs.org/w/index.php?diff=172433&oldid=172412 * * (-5) Fixed
01:05:07 <ais523> INTERCAL's select (i.e. PEXT) has come up in a number of contexts recently, in addition to being added as an instruction on x86, but mingle is less commonly used
01:06:56 <esolangs> [[User talk:Aadenboy/Countable]] M https://esolangs.org/w/index.php?diff=172434&oldid=172414 * * (-5) Fixed
01:38:32 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
02:02:19 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172435&oldid=172432 * A() * (+825)
02:29:05 -!- Sgeo has quit (Read error: Connection reset by peer).
03:06:09 -!- ais523 has quit (Quit: quit).
03:29:37 -!- Sgeo has joined.
03:49:51 -!- pool has quit (Read error: Connection reset by peer).
03:51:54 -!- pool has joined.
04:09:19 -!- rodgort has quit (Ping timeout: 240 seconds).
04:10:18 -!- rodgort has joined.
04:24:32 <esolangs> [[Countable]] https://esolangs.org/w/index.php?diff=172436&oldid=172426 * Aadenboy * (+44)
04:25:07 <esolangs> [[User:Aadenboy]] https://esolangs.org/w/index.php?diff=172437&oldid=172422 * Aadenboy * (+15) /* ESOLANGS */ add [[Countable]] to list of favorites
04:47:58 -!- impomatic has joined.
06:03:14 -!- scoofy has joined.
06:04:03 -!- somefan has quit (Remote host closed the connection).
06:23:19 <zzo38> It is often said that ASN.1 requires the use of a schema. Whether or not this is true depends on which format you are using; it is true for OER and PER but is not true for BER and DER. DER can be used without a schema (although it can also be used with a schema, which will be helpful if you want to handle data that contains implicit types, default values, etc, since those things are specified by the schema).
07:15:34 -!- tromp has joined.
07:29:07 -!- Sgeo has quit (Read error: Connection reset by peer).
07:44:02 -!- Yayimhere has joined.
07:49:36 <zzo38> Now I added another type into ASN.1X, which is called ASN1_SCIENTIFIC. It is like ASN1_REAL but the number of digits (or bits) is considered to be significant, and the canonical form for decimal numbers is different (there must be exactly one digit before the decimal separator, and trailing zeros are allowed and are considered to be significant).
08:20:51 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:33:48 <esolangs> [[Cammy]] https://esolangs.org/w/index.php?diff=172438&oldid=170868 * Corbin * (+55) /* Constants */ Add a constructor for ratios of nats.
09:07:06 <Yayimhere> oh yea korvo, I dont remember you telling me about neckties, but I took your recommendation, and am working on a blog right now
09:18:55 -!- Yayimhere has quit (Quit: Client closed).
09:21:58 -!- tromp has joined.
09:24:47 -!- Yayimhere has joined.
09:37:30 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
09:38:39 -!- Yayimhere has quit (Quit: Client closed).
09:40:13 -!- tromp has joined.
09:52:29 <esolangs> [[Book]] https://esolangs.org/w/index.php?diff=172439&oldid=171856 * Yoyolin0409 * (+23)
09:53:03 <esolangs> [[User:Yoyolin0409]] https://esolangs.org/w/index.php?diff=172440&oldid=172265 * Yoyolin0409 * (+0)
09:53:56 <esolangs> [[User:Yoyolin0409]] https://esolangs.org/w/index.php?diff=172441&oldid=172440 * Yoyolin0409 * (+21)
09:55:42 <esolangs> [[Do something]] https://esolangs.org/w/index.php?diff=172442&oldid=171609 * Yoyolin0409 * (-36) /* Do job */
10:11:37 <esolangs> [[\]] N https://esolangs.org/w/index.php?oldid=172443 * Yayimhere2(school) * (+1719) Created page with "'''\''' is a version of [[_/]], with a few simple modifications. It's based on an observation that none of the sub replacement patterns could interact with each other. It also uses another syntax. == Syntax / Semantics == A program is a list of "sub replacements",
10:12:11 <esolangs> [[/]] https://esolangs.org/w/index.php?diff=172444&oldid=168740 * Yayimhere2(school) * (+26) /* examples */
10:48:37 <esolangs> [[\]] https://esolangs.org/w/index.php?diff=172445&oldid=172443 * Yayimhere2(school) * (-103) /* Syntax / Semantics */
10:51:38 <esolangs> [[Rpg]] https://esolangs.org/w/index.php?diff=172446&oldid=172427 * Yoyolin0409 * (+487)
10:51:51 <esolangs> [[Rpg]] https://esolangs.org/w/index.php?diff=172447&oldid=172446 * Yoyolin0409 * (+3) /* Minsky machine(similar) */
10:53:05 <esolangs> [[Rpg]] https://esolangs.org/w/index.php?diff=172448&oldid=172447 * Yoyolin0409 * (-5) /* Minsky machine(similar) */
10:55:27 <esolangs> [[User:Yayimhere]] https://esolangs.org/w/index.php?diff=172449&oldid=172406 * Yayimhere2(school) * (+137) /* esolangs */
10:56:10 -!- ais523 has joined.
11:28:58 <fizzie> Oh, interesting coincidence. In Go 1.26, they're actually planning to introduce a new standard library component to expose architecture-specific SIMD operations, kind of like how it works in C with intrinsics. But the current version of the package -- https://pkg.go.dev/simd/archsimd@go1.26rc1 -- seems to focus exclusively on actual SIMD stuff, and doesn't have BMI2 (PDEP/PEXT).
12:05:35 -!- somefan has joined.
12:07:40 <ais523> meanwhile Rust already has the intrinsics, but is planning to add platform-independent pdep/pext, which is interesting with respect to how well the fallback will be optimised
12:07:56 <ais523> you almost want an INTERCAL-style optimiser at that point
12:08:23 <int-e> ais523: but nightly only?
12:08:29 <esolangs> [[User:Yayimhere]] https://esolangs.org/w/index.php?diff=172450&oldid=172449 * Yayimhere2(school) * (+82)
12:09:12 <ais523> int-e: the intrinsics are stable but platform-specific, I think: the platform-independent stuff is very new and still nightly-only
12:12:25 -!- ais523 has quit (Quit: quit).
12:12:44 -!- ais523 has joined.
12:12:49 <int-e> Oh. I guess I wasn't looking in the right place when I was looking for this: https://doc.rust-lang.org/stable/core/arch/x86_64/fn._pdep_u64.html
12:14:55 <int-e> (I didn't try *too* hard to find the intrinsic; https://paste.debian.net/hidden/3755060c isn't *too* terrible)
12:18:37 <int-e> ais523: so thanks for making me look harder
12:19:44 <ais523> there was a bit of a discussion about Rust documentation file sizes on the Rust internals forum recently, and the documentation for core::arch::x86_64 was mentioned
12:20:19 <ais523> so I had the appropriate location in medium-term memory already
12:22:11 <b_jonas> https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html is another large ones
12:22:27 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=172451&oldid=172425 * HerobrineMWB * (+221) /* Introductions */
12:39:44 <esolangs> [[User:Yayimhere]] https://esolangs.org/w/index.php?diff=172452&oldid=172450 * Yayimhere2(school) * (+23) /* ppl i like and dont like */
12:48:33 <esolangs> [[User:Hotcrystal0/Sandbox]] https://esolangs.org/w/index.php?diff=172453&oldid=171777 * Hotcrystal0 * (+223)
13:08:37 -!- ais523 has quit (Quit: quit).
13:22:57 -!- ais523 has joined.
13:41:00 <fizzie> Sadly you can't inline assembly in Go, and functions written entirely in assembler (which you can have) are limited to the much less performant (but stable) "ABI0" calling convention (whereas compiler-generated code can use the faster but unstable "ABIInternal"), and never get inlined, so the "just do it yourself" approach is much less feasible in terms of performance.
14:33:35 <esolangs> [[Talk:Input hello world or else:]] N https://esolangs.org/w/index.php?oldid=172454 * * (+541) Created page with "I came here in 14 redirects. <span style="background-color: green;">[[User:|<span style="color: white;">mario</span>]]</span><span style="background-color: yellow;">[[User talk:|<span style="color: black;">maker</span>]]</span><span style="background-col
14:37:37 <esolangs> [[EmojiStack/Codepage]] https://esolangs.org/w/index.php?diff=172455&oldid=155294 * * (-1)
14:37:52 <esolangs> [[Special:Log/move]] move * * moved [[EmojiStack/Codepage]] to [[Mojifunge/Codepage]]
14:38:05 <esolangs> [[User:Yayimhere2(school)]] https://esolangs.org/w/index.php?diff=172458&oldid=172270 * Yayimhere2(school) * (-135) Redirected page to [[User:Yayimhere]]
14:40:53 -!- pool has quit (Read error: Connection reset by peer).
14:41:27 -!- pool has joined.
14:54:15 <esolangs> [[User:MihaiEso]] https://esolangs.org/w/index.php?diff=172459&oldid=170246 * MihaiEso * (+71)
15:01:36 -!- amby has joined.
15:21:01 <esolangs> [[Unspoken]] N https://esolangs.org/w/index.php?oldid=172460 * Yayimhere2(school) * (+680) Created page with "'''Unspoken''' is an encoding of [[Apraxia]], to be able to be used as poetry. It is directly equavilent to Apraxia, other than input. == Encoding == In Unspoken, the "characters"/tokens of Apraxia are replaced with "words", which are strings of. When execut
15:21:12 <esolangs> [[Unspoken]] https://esolangs.org/w/index.php?diff=172461&oldid=172460 * Yayimhere2(school) * (-18)
15:31:48 <esolangs> [[AddByteJump]] N https://esolangs.org/w/index.php?oldid=172462 * Timm * (+215) Created page with " A B C do A* =+ B* jump C (?) is actual value<br> -? is negation<br> -(?) you get it<br> (its low-level)<br> -1 in A make output, B input and C make halt<br> -2 has 1 always<br> -3 has -1 always<br> {{Made|Timm}}"
15:32:40 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
15:33:04 <esolangs> [[User:Timm]] https://esolangs.org/w/index.php?diff=172463&oldid=171289 * Timm * (+19)
16:02:54 -!- tromp has joined.
16:15:32 <sorear> riscv has mingle but not select, somewhat odd (early bitmanip drafts had both but "we need zip for 32-bit keccak" was somehow judged as a more real use case than anything presented for pext)
16:24:59 <sorear> strange to define a SIMD interface in 2026 that doesn't have first-class support for scalable types
16:36:03 <ais523> scalable vectors are, oddly, quite hard to handle at the programming language level
16:36:27 <ais523> especially if you try to fit them into the same sort of programming language API as fixed-length vectors
16:37:12 <ais523> the intention of the scalable vector machine code instructions is that you write software that doesn't care about the vector length, and yet most existing explicit-vectorisation APIs expect it to be cared about by the software rather than the compiler
16:38:25 <ais523> I really don't like the current state of vectorisation, autovectorisation is too inconsistent (both in terms of whether it happens and in terms of whether the result makes sense or not) and manual vectorization is too manual
16:40:45 <esolangs> [[Bliss]] M https://esolangs.org/w/index.php?diff=172464&oldid=171156 * H33T33 * (+4)
16:42:56 <esolangs> [[Bliss]] M https://esolangs.org/w/index.php?diff=172465&oldid=172464 * H33T33 * (+25)
16:47:26 <esolangs> [[Special:Log/newusers]] create * Emulao * New user account
17:45:56 <esolangs> [[C*]] https://esolangs.org/w/index.php?diff=172466&oldid=166807 * H33T33 * (+717)
17:47:35 <b_jonas> I do mostly like the current state of SIMD code. We write code using SIMD primitives that compilers can directly emit as instructions, while the compilers figure out register allocation and scheduling and similar. Vector scaling is limited, it exists only as much that you can write code assuming 64 byte wide vectors, some processors will run the instructions directly but with some or all operations on
17:47:41 <b_jonas> 32 byte wide execution units, and the compiler can recompile the code emulating the 64 byte wide operations with 32 byte wide instructions which is not optimal but at least works.
17:48:22 <b_jonas> There are a few details that I don't like of course, but this mostly works well. Obviously there's a big delay between when the CPU instruction sets are designed and when most software adapts them, but that's fine, anything else would be premature optimization anyway.
17:48:47 <ais523> at least on x86, 64→32 compiling is difficult because only the AVX-512 instructions support 64-byte vectors, but they also support other features like writemasks that can't be compiled down to AVX2
17:49:19 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:53:54 <b_jonas> I'm not very fond of masking and that part of the design of AVX2. It's kind of an inefficient use of CPU resources, with the completely separate mask registers and instructions for them instead of just using normal registers as masks with bitwise operations like we're doing in AVX2.
17:54:26 <ais523> I can certainly see an argument for, e.g., using r8…r15 as mask registers
17:55:17 <ais523> but Intel seem to have decided recently that they still don't have enough registers
18:00:09 <int-e> (who needs context switches anyway)
18:00:56 <int-e> (you know, that thing where you routinely save all registers and restore another set of values from memory)
18:01:21 <sorear> avx-512 has had 32 architectural vector registers from the beginning
18:01:54 <ais523> Intel announced that they were going to add new GPRs as well, though (although it doesn't seem to have hit the instruction set docs yet, so maybe it's not actually available for sale at the moment)
18:01:56 <sorear> and the mask registers are much smaller than the vector registers, why engage a 512-bit data path if you only need one bit per element?
18:02:26 <ais523> sorear: I think b_jonas is arguing that the masks should have been taken from GPRs rather than from their own register type
18:02:39 <ais523> they're exactly the right size (64 bits)
18:02:47 <ais523> maybe this is futureproofing for AVX-1024?
18:03:00 <b_jonas> I'm arguing that we should be using the XMM/YMM/ZMM registers for masks
18:03:30 <b_jonas> (though there is one instruction to transfer them to a GPR, useful for condition testing in strlen and similar)
18:03:40 <sorear> the degree of coupling between the integer and vector (hardware) scheduling that implies would be a nightmare
18:04:22 <b_jonas> "maybe this is futureproofing for AVX-1024" => the futureproofing was that AVX512W already had instructions for 64-bit mask registers even though only AVX512B needs them
18:05:09 <b_jonas> there won't be an AVX1024, AVX is stopping here because cache lines are 64 bytes wide
18:05:49 <b_jonas> if you want wider, there's AMX (Advanced matrix extensions) with the "tile registers"
18:05:57 <b_jonas> specifically for matrix multiplication
18:10:35 <sorear> the 3-operand 32-register integer ISA is an interesting development, much more similar to the others and A64 in particular, I think that leaves s390x as the most relevant 16-integer-register ISA? the high-word facility can do some similar things but it's equally weird as the newest implementation of subregisters
18:12:05 <ais523> b_jonas: 64-byte cache lines isn't a fundamental rule, though, right? that one could be changed
18:13:11 <b_jonas> yes, but they are hard to change and would affect a lot of other things. it might reduce the performance of non-vector programs.
18:14:07 <ais523> glad to see that with APX, the instruction encoding still doesn't make any sense :-D
18:16:57 -!- tromp has joined.
18:23:38 <ais523> I wonder what the performance gain would be like if x86-64 had a sensible instruction encoding (the main advantage would be in saving L1c cache, and I'm not sure to what extent that matters) – my guess is that it would be small
18:24:31 <sorear> surely that would depend on the segment
18:26:23 <sorear> the big cores do fairly involved pre-decoding to a "µop cache" (beware that µop is a loaded term and the things in the cache aren't necessarily what might be called a µop in any other context)... but if you're trying to achieve >6 IPC you need a trace cache _anyway_ because there are too many taken branches
18:27:54 <ais523> sorear: I think the trace/loop/µop caches probably aren't relevant to this, which is why L1c is the first relevant layer
18:28:30 <ais523> although, a sensible encoding would likely be easier to decode, meaning you could get more encoding parallelism or maybe a shorter pipeline, and both of those would give performance gains in certain contexts
18:30:17 <ais523> (by "aren't relevant" I mean that although the caches are relevant, changing the instruction format wouldn't make their performance any better or worse, so it's other parts of the processor we have to look at in order to gauge the impact)
18:32:07 <sorear> i think I1$ mostly cares about size, and "how much does size matter" is ... intensely debated
18:33:39 <ais523> indeed, I have seen a lot of plausible arguments in both directions but don't know what to conclude from them, and benching this is almost impossible due to alignment effects
18:34:06 <ais523> so although in theory there should be an objective answer, it is difficult to determine what it is
18:36:51 -!- ais523 has quit (Quit: quit).
18:40:40 <esolangs> [[User:FluixMakesEsolangs/Secret]] N https://esolangs.org/w/index.php?oldid=172467 * FluixMakesEsolangs * (+241) SHHHH SEECCREEEETTT
18:47:05 <esolangs> [[Unspoken]] https://esolangs.org/w/index.php?diff=172468&oldid=172461 * Yayimhere2(school) * (+43) /* Encoding */
19:00:44 <esolangs> [[User talk:FluixMakesEsolangs/Secret]] N https://esolangs.org/w/index.php?oldid=172469 * * (+25) Created page with "how do i spoil people >:)"
19:01:49 <esolangs> [[Talk:2026]] N https://esolangs.org/w/index.php?oldid=172470 * * (+43) Created page with "2026 is equivalnet to Python for this year."
19:05:03 <b_jonas> ais523: I'm nto sure it would still count as x86 if you ripped out the current instruction encoding entirely. There were a few changes made when 64-bit mode was introduced, some of the old encodings are invalid in 64-bit mode to free up encoding space.
19:05:21 <b_jonas> But if you just replace the entire encoding then you get a new architecture.
19:05:55 <b_jonas> although I think ARM has like four different instruction encodings by now
19:08:37 <sorear> 3 main ones? I don't think Streaming SVE Mode counts
19:09:01 <esolangs> [[User talk:FluixMakesEsolangs]] N https://esolangs.org/w/index.php?oldid=172471 * Corbin * (+1051) Created page with "Hi! Welcome to the wiki. I know you've been here for a while, but it seems that I'm the first person to greet you. '''You haven't done anything wrong''' but I wanted to let you know a few things: * Please read [[esolang:policy]] if you haven't alrea
19:34:05 <b_jonas> could be. I'm not too familiar with ARM, I'm mostly just looking at x86_64 all the time.
19:35:31 <sorear> I think «a new architecture» means different things to different audiences
19:36:33 -!- Lord_of_Life_ has joined.
19:37:28 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
19:37:39 <b_jonas> yeah, I mean you could have something like x86_16 vs x86_32 protected mode where the same program can far jump between the two and share the same registers and call functions with arguments in registers and stack, in which case it wouldn't be an entirely separate architecture
19:37:52 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:38:28 <b_jonas> binary compatible, just link your new code together with the old code and make the processor dynamically switch decoding mode between them using a flag register
19:39:12 <b_jonas> which is kind of what we have between AVX and AVX2
19:41:24 <sorear> ia64 could dynamically switch decoding mode and had switch instructions (br.ia32 / JMPE)... not quite as seamless as 386 call gates
19:42:11 <b_jonas> I think 386 doesn't even need call gates to jump between 32-bit and 16-bit user-mode code, just different code segments
19:42:29 <b_jonas> call gates are for jumping to kernel mode or similar
20:45:57 <esolangs> [[A-SCP-M]] https://esolangs.org/w/index.php?diff=172472&oldid=125586 * Scp-999 * (+267) Added JMod to improve containment protocol
20:50:30 -!- Everything has joined.
20:52:47 -!- ais523 has joined.
20:53:52 <ais523> ARM has a scheme in which two of the encodings can coexist based on whether the instruction pointer is odd or even
20:53:56 <ais523> (because both of them are aligned to 2)
20:54:25 <ais523> the only existing programs that this would break would be those that assumed function pointers were always even
20:55:03 <ais523> (the IP effectively points to the second byte of the instruction rather than the first in the newer encoding, so the instructions stay aligned – you can also think of it as the IP being low-bit-tagged and I think that's how it's documented)
20:55:48 <esolangs> [[Clowder]] N https://esolangs.org/w/index.php?oldid=172473 * Profboady * (+12434) Submit first draft of language specification for Clowder and Quantum Assembly Language.
20:56:04 <b_jonas> ais523: yes, that works. The other scheme that you can do is make sure that a small part of the instruction encoding overlaps so that you can write a short polyglot that switches into the correct instruction set.
20:57:36 <ais523> I guess another approach would be to reserve a fraction of a bit in the page tables to specify the encoding when executing from that page (it's less than a bit of information because you can use it for something else if the NX bit is set)
20:57:42 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=172474&oldid=172429 * Buckets * (+14) /* U */
20:57:52 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=172475&oldid=172474 * Profboady * (+14) I added my language clowder to the main list.
20:58:21 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=172476&oldid=172430 * Buckets * (+13)
20:58:30 <esolangs> [[Mot]] N https://esolangs.org/w/index.php?oldid=172477 * Buckets * (+578) Created page with "Mot is an Esoteric programming language Created by [[User:Buckets]] In 2020. {| class="wikitable" |- ! Commands !! Instructions |- | > || Output the Current number. |- | @ || Skip the next Command if The value = 0. |- | ? || Reset this line. |- | { || Goto the Next {. |- |
20:58:31 <b_jonas> x86_16 vs x86_32 protected mode does something like that but with the segment descriptor instead of the page table
20:58:40 <esolangs> [[Unsidue]] N https://esolangs.org/w/index.php?oldid=172478 * Buckets * (+855) Created page with "Unsidue is an Esoteric Programming language created By [[User:Buckets]] in 2021. {| class="wikitable" |- ! Commands !! Instructions |- | [m] || Modulo the current Number by m, if there's Residue, Move That many Times forward of A # such As a residue Of 2 would Goto the
20:58:54 <sorear> less of a scheme and more of an original sin
20:59:00 <ais523> now I'm reminded of the way that Linux can emulate the system call ABIs of various old UNIXes, in order to run some of their executables without recompiling
20:59:37 <esolangs> [[User:Profboady]] N https://esolangs.org/w/index.php?oldid=172479 * Profboady * (+124) Created page with "I am Mark Boady, a computer science professor who works at Drexel University. More about me at [https://boady.net boady.net]"
20:59:37 <b_jonas> hehe, that would be funny, making the writable bit of the page to mean an alternate instruction set, if you had previously forbidden the same page table entry to have both executable and writable (you could still write through a different page aliased to the same physical addres)
20:59:40 <sorear> the oldest arm was limited to 26-bit address space because they decided "we don't need a saved PSR, we can just use the spare bits in the exception link register"
21:00:08 <sorear> they moved most of the flags out but "thumb/arm mode is bit 0 in LR" feels like a relic of that paradigm
21:00:46 <ais523> I guess a link register inherently has the same encoding as the instruction pointer, so that makes sense
21:01:44 <b_jonas> ais523: "emulate the system call ABIs of various old UNIXes" => don't they have like three different system call ABIs for x86_32, plus two x86_64 ABIs, plus windows system calls through Wine derivatives, plus FreeBSD system calls if it's a FreeBSD kernel?
21:02:12 <b_jonas> possibly multiple different Windows system call ABIs at the same time
21:02:21 <ais523> x32 (the less commonly used x86-64 ABI) is weird
21:02:41 <sorear> none of the windows or freebsd stuff is in linux proper, whereas mips linux _does_ pretend to be an irix kernel under certain conditons
21:02:55 <b_jonas> only I think you can't really mix x86_64 and x86_32 code in the same unix process, so that limits how many of the ABIs are active at the same time
21:03:08 <b_jonas> sorear: no, but the Linux ABI is in FreeBSD kernels
21:03:08 <ais523> Wine isn't built into the kernel as far as I know
21:03:08 <ais523> but I guess it technically could be!
21:03:10 <ais523> IIRC most BSDs don't have a stable kernel interface, you have to go via libc
21:03:28 <b_jonas> ais523: not the kernel, but the kernel allows Wine to catch the Windows syscall abi in userspace, right?
21:03:42 <sorear> I believe "page table bit to select instruction encoding" is how powerpc vle works
21:04:09 <sorear> also enables BTI on arm and epc on ia64 but those are less dramatic
21:04:19 <ais523> b_jonas: thinking about that that's probably what PTRACE_SYSEMU is for
21:05:19 <esolangs> [[User:Hotcrystal0/Sandbox]] https://esolangs.org/w/index.php?diff=172480&oldid=172453 * Hotcrystal0 * (+0)
21:05:25 <ais523> "run this progam until the next system call, then skip the system call" doesn't have an obvious purpose for native executables, but it would be helpful on an executable for a different OS
21:06:06 <b_jonas> that does have an obvious use for debugging and reverse-engineering a program if it may call system calls not through a libc that you're familiar with
21:06:17 <ais523> although, on Windows the standard way to make system calls is to dynamically link against a few system-provided shared libraries that make them for you, so all this time I assumed that Wine worked just by providing Linux implementations of the libraries
21:06:23 <b_jonas> you can even examine the system calls that it makes
21:06:26 <b_jonas> isn't that what strace does?
21:06:45 <sorear> i think wine mostly works at the ntdll level, the ring0-ring3 ABI changes between windows builds anyway
21:06:45 <ais523> b_jonas: there's a variant of that which *doesn't* skip the system call, that's what strace uses
21:07:16 <ais523> because strace still wants the system calls to happen, it just wants to observe them
21:07:18 <b_jonas> ok, but for a debugger it can still make sense to examine the system call before it decides to execute it or not or possibly execute a modified or emulated version.
21:07:32 <ais523> you can do that even with the version that doesn't skip by default
21:07:44 <ais523> but you have to modify the program's registers to change the system call number
21:07:49 <sorear> wine _does_ provide linux implementations of the libraries, you can link Windows C code directly against them and bypass the EXE loader (winelib)
21:07:57 <ais523> (it halts on entry to the system call, and optionally on exit too)
21:08:38 <ais523> I think there's a system call number that's guaranteed to do nothing, probably -1
21:09:33 <b_jonas> 29 for pause, just send a SIGCONT?
21:10:13 <b_jonas> or maybe modify the system call to time(0)
21:10:38 <b_jonas> so 13 with the first argument a nullptr
21:10:40 <sorear> I'd do NR_getpid if there isn't a dedicated skip
21:10:59 <b_jonas> sorear: that works too, yes
21:12:22 <b_jonas> you can give arguments to many syscalls to make them a noop, sometimes with an error
21:12:53 <b_jonas> even just a read with file descriptor 0 could wrok
21:13:06 <b_jonas> no, sorry, read with file descriptor -1
21:14:27 <sorear> register handling across ptrace stops is a big mess and I'm not confident in my understanding of it
21:20:23 <ais523> I *used* to know how it worked, but haven't looked into it for ages and have forgotten many of the details
21:21:25 <ais523> oh wow, this program gets silly even in the header file includes, it needs to include both struct stat from <sys/types.h> and struct stat from <asm/stat.h>, which are different structures with the same name
21:21:35 -!- impomatic has quit (Quit: Client closed).
21:24:09 <ais523> there is the classic "I want to replace one system call with two, so I will rewind the IP two bytes so that the program hits the same system call instruction again"
21:24:33 <ais523> (both syscall and int 0x80 are two bytes long and I was doing this on x86/x86-64)
21:25:55 <sorear> things which also happen with SA_RESTART
21:26:55 <ais523> sorear: OK, so the way it works on x86(-64) is that when you request the registers from the process, there are *two* ?ax registers: the orig_ one contains the system call number, the one with the plain name contains the system call return value (which is -ENOSYS at the point in the kernel at which the system call gets interrupted)
21:27:08 <ais523> and changing them on system call entry will change the kernel's view of them too
21:28:52 <ais523> to disable system calls I just used an arbitrary unlikely number and then got ENOSYS back
21:29:20 <b_jonas> ais523: aren't there like four different stat system calls with different types for historical reasons, but only on x86_32, and all but the last one got eliminated on x86_64?
21:29:57 <ais523> b_jonas: it wouldn't surprise me, it's very common for system calls to be near-duplicated with a different ABI
21:30:14 <sorear> the stat structure has changed several times when people decided that no, 32-bit ints aren't enough for file sizes
21:30:18 <ais523> x86 has uname, olduname and oldolduname system calls
21:30:46 <b_jonas> I haven't looked into the details, I just had gdb magically do function calls in the debugged process for me
21:31:08 <b_jonas> and even that was many years ago; these days I only do printf debugging, putting debugging code right into my program without any special library or debugger
21:31:56 <sorear> most recently time_t but stat handling is a bit odd there - on the kernel side plain stat was deprecated instead of being extended so you have to migrate to statx for Y2038
21:32:15 <sorear> but statx is not POSIX so the libcs invented a 64-bit-time struct stat that doesn't exist in the kernel
21:35:03 <ais523> I dislike the way system calls are normally done through libc – it seems preferable to me to have two libraries, one which just provides a platform-agnostic way to do things that only the kernel can do, and one which is entirely portable (maybe calling into the first library)
21:35:08 <b_jonas> it gets funny, leads to situations where you have one header file that calls the system calls oldoldstat, oldstat, stat, stat64; then another header files that calls them oldstat, stat, newstat, stat64; then a third that only lets you access the last two and calls them stat and stat64 but makes stat an alias to stat64 depending on what macros are set
21:35:47 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172481&oldid=172435 * A() * (+0)
21:36:12 <ais523> that way, non-C languages wouldn't have to depend on C baggage like printf and FILE* buffering, and the OS-portable and non-OS-portable parts of the C library seem easier to maintain separately in order to reduce duplication of effort between platforms
21:36:19 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172482&oldid=172481 * A() * (+30) /* A+B */
21:36:49 <b_jonas> ais523: sure, but libc does too many things partly for historical reasons, partly so that system calls can set errno which is a macro that emulates a thread-specific variable but from before C had first-class thread-specific variables or something like that
21:37:27 <ais523> I don't think threads even existed in the early days of errno, it was just a global
21:37:41 <ais523> and then it had to be made thread-local for correctness reasons when threads were invented
21:39:08 <sorear> people always use printf as the example but I think the actually painful parts wouldn't be solved by splitting the library
21:39:51 <b_jonas> printf is the part that I want to have even in rust, because the floating point formatting bit is really hard to implement correctly and efficiently
21:40:58 <esolangs> [[Error quine]] M https://esolangs.org/w/index.php?diff=172483&oldid=167414 * Photostar * (+181)
21:41:00 <b_jonas> But I don't think it's too big a deal that libc is as big as it is. You don't have to use all of it, and the parts that you don't use aren't a big expense.
21:41:06 <ais523> sorear: the most painful to me is actually things like gethostbyname – because on glibc those are implemented using shared-library dependencies that can't be statically linked, meaning that you can't make a system call without linking in the whole dynamic linking infrastructure
21:41:55 <b_jonas> ais523: yes, but if you don't want to then you don't have to use those parts.
21:42:01 <ais523> b_jonas: it's totally fine to have a nice self-contained portable sprintf library, but why does it have to come with the OS?
21:42:20 <ais523> and the mere fact that it exists, whether or not you use it, causes the problem
21:42:22 <sorear> on a reasonable platform we'd have some form of RPC dependency injection for that
21:42:34 <b_jonas> it has to come with the OS so that my RAM isn't full with ten different libcs, but only one libc mmapped in every process
21:43:09 <b_jonas> that's one thing that Debian does well, they're actively working on programs sharing just one copy of each library, not just libc
21:43:16 <ais523> b_jonas: well this is the major argument for shared libraries in general
21:43:29 <b_jonas> yes, I want shared libraries for everything. I don't like static libraries.
21:43:57 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172484&oldid=172482 * A() * (+238)
21:44:34 <ais523> I mean, libc in particular
21:44:49 <b_jonas> and yes, there will always be some code duplication, the sharing won't be perfect, but I want to tend towards sharing. that also helps make sure that when I update my system packages to fix a security bug then it's fixed in all programs, that I'm not running programs with their own obsolete and never updated copy of a library that's full of security holes.
21:45:09 <b_jonas> yes, shared libc too, and ideally shared libraries for rust
21:45:37 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172485&oldid=172484 * A() * (+33)
21:46:32 <ais523> I've been considering writing a platform (that runs alongside regular x86-64 executables on the same Linux kernel but isn't ABI-compatible with them) for which the only things you can dynamically link are the system call library, the allocators (which have to be platform-provided for some reason I can't remember right now but I think it involves address space), and major language-support libraries like libc
21:46:56 <b_jonas> why would you limit what you can dynamically link?
21:47:00 <ais523> using more shared libraries than that, in practice, doesn't seem to help in practice on anything other than Debian-like "all these versions work with all those version" curate systems
21:47:27 <ais523> if install a program from outside the repositories, it normally comes with its own copies of the system's shared libraries and links to those except on the system
21:47:48 <ais523> package formats like Snap and Flatpak come with all the shared libraries bundled, they don't use the system's
21:47:58 <ais523> * links to those instead of those on the system
21:48:12 <b_jonas> yes, and I don't like those package formats, partly for the reasons that I explained above.
21:48:18 <sorear> how does that work with libGL?
21:48:45 <ais523> lots of people/companies run their programs in containers, and have to put separate shared libraries into them (which could in theory be bind-mounted but in practice I think they're almost always container-specific)
21:49:02 <esolangs> [[Confusion]] M https://esolangs.org/w/index.php?diff=172486&oldid=168431 * Mun Hammer * (+21) shouldn't be first person
21:49:22 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172487&oldid=172485 * A() * (+14)
21:50:02 <ais523> sorear: I'm not sure, I'm not familiar with how that works internally
21:50:32 <ais523> (but I searched my directories of unpackaged software and didn't find any libGL, but I did find several copies of libGLEW)
21:53:05 <ais523> communication with GPUs and windowing systems might in practice be the same sort of problem as communication with kernels
21:53:46 <ais523> b_jonas: in any case, I think the reason most people don't share shared libraries is that it's too much effort to try to keep the programs compatible with them
21:54:25 <ais523> Debian goes to a lot of effort in testing "this version of this program works with that version of that library" but outside a distro's package manager it's almost impossible
21:54:31 <sorear> most libraries aren't designed to have a long-term-stable ABI
21:56:17 <ais523> my personal reason to want to limit the number of shared libraries is that it allows you to give them fixed load addresses relative to each other and the program that links to them, making the dynamic linking step trivial – you lose a little ASLR power but ASLR is pretty easy to bypass anyway nowadays, and gain security from not having dynamic-linker-ish things happening in your executable at all
21:56:40 <ais523> so many exploits that exploit parts of the memory map that only exist due to the dynamic linker
21:57:39 <ais523> I *would* allow dlopen, but not for providing functions to call or be called directly, you would have to use a dlsym equivalent in order to get function pointers at runtime (meaning that no dynamic linking step would be needed there either)
21:58:30 <ais523> oh no, I think I've hit a really stupid ambiguity in English – "providing a function to call" could be "providing a function that you can call" or "providing a function that does calling"
21:59:42 <sorear> how does the dlopened image allocate memory, make system calls, etc?
22:00:12 <b_jonas> ais523: does that mean you wouldn't allow dispatching between different versions of a library at dynamic link time without function pointers that have a runtime cost each time you call the function?
22:00:58 <sorear> all calls between dynamic libraries are done via function pointers at the ISA level, PLT/GOT
22:01:06 <ais523> sorear: I was considering a few different plans for that, ideally I'd like the dlopened images to use fixed offsets for that too but that doesn't work if you dlopen more than one library at a time, unless you double-map the system call library
22:01:30 <ais523> or at least that you ensure you don't dlopen two images with the same offset
22:01:51 <sorear> I wouldn't consider double-mapping a problem but what if the dlopened image has a link-time dependency on a different version of the system call library?
22:01:56 <ais523> the main purpose of dlopen is for providing plugins and the like, if those are tied to the executable then avoiding offset clashes should be a solvable problem
22:02:22 <ais523> sorear: this is why I would want the system call library to be as small as possible, it would make it easier to keep the ABI stable
22:02:42 <ais523> if you created a new version of a function you would have to leave the old one around
22:03:53 <ais523> b_jonas: at dynamic link time, indeed – for some of those problems you can solve them at static link time instead and just generate multiple executables, but there are probably some cases that wouldn't solve
22:04:09 <ais523> (although, you have function pointer cost *anyway* in the usual current way of doing things)
22:04:42 <b_jonas> ais523: my problem is that if I'm forced to use dlsym then the burden of type safety for the function calls is always on me. I'm find with allowing that for some cases, and it's almost always necessary when linking compilation units cross-language or with cyclic dependencies, but sometimes I just want the simple way when I set a dynamic library crate dependency at runtime and the rust/haskell compiler
22:04:48 <b_jonas> ensures at compile time that I'm doing typesafe calls across crates.
22:05:23 <ais523> b_jonas: I would encourage people to statically link in that situation
22:05:53 <ais523> it is worth noting that at least the current Rust compiler is not appropriate for this situation, it will check that the types match at the source level, but does not compile them consistently at the binary level
22:06:21 <ais523> so you can have types that match in the source code but go wrong when the binaries communicate
22:06:58 <b_jonas> yeah, you can probably only do that if you always compile the crates together and with the same options, at which point you might as well link them statically
22:08:30 <b_jonas> hopefully future versions of rustc will at least be able to check the typesafety at binary level and give an error when something is incompatible, even if they can't solve that
22:08:55 <ais523> doing that on a *dynamic* link would be… interesting
22:09:14 <b_jonas> I guess you're making a reasonable case for why static linking is better *in practice*, even if dynamic linking is what I want in some idealized world
22:09:20 <ais523> it isn't theoretically impossible, but I don't know whether you'd implement it in the dynamic link or in the implementation of / wrapper around dlopen
22:09:24 <ais523> * in the dynamic linker
22:09:47 <b_jonas> why? you just mangle the full type description (or at least a cryptographic hash of it) into the dyanmically linked symbol names
22:10:01 <ais523> oh, I didn't even think of that
22:10:16 <b_jonas> at least as much of the type description as matters for the ABI that is
22:10:20 <ais523> right, mangling the ABI (as opposed to type name) would work
22:11:13 <ais523> that technique might be useful for the typed-asm thing I've been thinking about, it'd let you do the type checking before the linker and yet still use a regular linker to link the resulting files together
22:11:47 <ais523> by encoding the type assumptions into the name of everything that's linked across compilation units, so if the types don't match, the link fails
22:11:55 <ais523> …isn't this just "Hungarian notation for linkers"?
22:13:01 <sorear> rust _does_ mangle cryptographic* hashes into dynamically linked symbol names, it's weird that it doesn't include enough information to catch memory safety issues
22:13:58 <ais523> the Rust name mangling situation is complicated, and I'm not sure I fully understand it
22:14:11 <sorear> (* not long enough to be collision-safe, but the system can't protect against attacker-controlled binaries anyway)
22:14:54 <ais523> there has been a lot of discussion about whether the hashes used by TypeId are even strong enough to be safe against *accidental* collisions
22:15:14 <ais523> but the symbol name hashes are different, I think (but might be using the same algorithm?)
22:15:14 <b_jonas> I have vague plans for a C interpreter that helps run untrusted code, with stronger guarantees about undefined behavior than is usual for most architectures, and that would always know the type of functions modulo compatibility. I'll probably never actually do that project. Obviously you can still get a function call incompatible at a higher semantics level, which is why it's good practice for the
22:15:20 <b_jonas> programmer to rename a function whenever its semantics changes, and possibly provide wrappers with the old name. I had series of such functions in code for my previous job.
22:15:47 <ais523> in any case, Rust's very slowly moving towards "v0 mangling" (which is a weird name to give the second major version of your mangling scheme), and I think that doesn't use hashes at all
22:16:52 <ais523> semi-recently they upstreamed demanglers for v0 mangling into a lot of unusual places, including the Linux kernel repository (but I think it was upstreamed into a userspace executable that's part of it, rather than the kernel source)
22:16:56 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=172488&oldid=170626 * A() * (+255) /* Proposed category: Data structures */
22:17:06 <b_jonas> I'd probably save the whole type description, not just a hash, though a hash may also be there for quick comparison.
22:17:46 <sorear> does the v0 mangling encode enough information to enforce memory safety at link time and how large is it?
22:18:09 <b_jonas> Sure, you want to be able to remote debug a virtualized kernel instance, and the debugger (eg. gdb) should know about mangled names in that case.
22:18:44 <b_jonas> I'm not big on interactive debuggers, but if you're developping the linux kernel or something else that works with hardware then it's indispensible.
22:18:50 <sorear> (if symbol tables had slightly more structure than just strings we could make them smaller and have much faster bulk lookup)
22:18:59 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172489&oldid=172487 * A() * (+19)
22:20:20 <ais523> <sorear> does the v0 mangling encode enough information to enforce memory safety at link time and how large is it? ← it won't catch situations where you compile against one version of a crate and link against a different version in which types have the same name but are defined differently
22:21:09 <sorear> (don't think about dlsym. if you're loading library A which has N undefined symbols and library B has M defined symbols, that is a JOIN)
22:21:38 <ais523> the format does aim to optimize size subject to a few other constraints, the ones which are in the biggest tension are probably "can demangle to produce a human-readable type name containing all relevant information" and "computationally inexpensive to encode/decode"
22:22:38 <ais523> https://doc.rust-lang.org/nightly/rustc/symbol-mangling/v0.html seems to be the current spec
22:22:53 <b_jonas> ais523: what I'd like is that when a new rustc version changes ABI and you link code compiled with different rustc versions, possibly compiled with different options, then you can't accidentally get a silent ABI mismatch from that, but you get an error at dynamic link time.
22:23:12 <sorear> if ELF symbols were represented as a DAG you could have all that information without repetition or slowing down links
22:23:25 <ais523> b_jonas: I think that's a reasonable thing to want
22:24:12 <sorear> repr(Rust) is "unstable" but how many times has it actually changed since 1.0?
22:24:39 <b_jonas> you could also catch some accidental ABI mismatches that are a fault of the person who writes the code. you can't catch all of these because the programmer can just cause deliberate UB with unsafe code, but it could catch some mistakes.
22:24:41 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:24:48 <ais523> sorear: quite a lot I think, mostly with respect to enums
22:25:23 <ais523> some of the changes are spec changes, though, I think
22:25:37 <ais523> as in, they're fully binary compatible both ways, just the guarantees changed
22:26:14 <b_jonas> the current solution is to just make the cross-crates ABIs a stable C ABI as if you were linking code from another language, with a thin source code wrapper on one side of the ABI boundary that contains the type same as a C header file would in C or C++
22:26:30 <ais523> there's an unstable option that randomizes field order in repr(Rust) structs, possibly subject to not having to introduce extra padding
22:26:37 -!- molson__ has joined.
22:26:38 <ais523> with that option, repr(Rust) changes every compile
22:26:42 <b_jonas> and I think this isn't an unreasonable solution exactly because that's what you want to be able to do to link between languages, such as to link between C++ and rust
22:27:02 <b_jonas> so this should always be supported, but there could be more optimized easy cases in addition to this
22:27:25 <ais523> b_jonas: right, Rust linking to itself via a C ABI is the recommended (and only reasonable corrrect) way to do it atm
22:28:00 <b_jonas> this isn't just Rust, you can do this in Haskell too, it's just harder with Haskell because it's harder to write C ABIs that match the Haskell code well
22:28:20 <b_jonas> or for linking a C++ library into perl or python
22:29:14 -!- molson_ has quit (Ping timeout: 260 seconds).
22:29:46 <b_jonas> or linking C++ code with rust code, which is the most practically relevant case for me
23:11:42 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=172490&oldid=172488 * Corbin * (+459) /* Proposed category: Data structures */
23:12:26 <esolangs> [[Esolang talk:Categorization]] M https://esolangs.org/w/index.php?diff=172491&oldid=172490 * Corbin * (+1) /* Proposed category: Data structures */ Fix fragment.
23:15:45 <zzo38> I think that "run this progam until the next system call, then skip the system call" can be useful for native programs, if you can change the effect of system calls by doing something else instead, although the way that such a thing works in Linux is perhaps not as well, due to many things including there are a lot of system calls.
23:16:51 <zzo38> My idea of a operating system design though would have the suggested way for a system call to do nothing would be "wait for all objects in a empty set to be ready", and the usual way to terminate a program is "wait for any object in a empty set of objects to be ready".
23:23:29 -!- Sgeo has joined.
23:46:15 <esolangs> [[Gur yvsr]] M https://esolangs.org/w/index.php?diff=172492&oldid=172318 * Placeholding * (+2) fixed mistake in first bad example