00:00:39 <avih> ais523: can your interpreter optimize over what ends up as nesting loops in bf?
00:00:44 <ais523> well, a bignum can be used to store arbitrary amounts of data (pretty much by definition), and some programs do that as an alternative to using multipel tape cells
00:01:03 <ais523> the waterfall model uses a different control flow scheme, but effectively yes
00:01:56 <ais523> it works by tracing round sequences of execution that actually happened to see whether they're exact repeats except that some cells increased/decreased by constants without any successful zero tests on them
00:02:01 <avih> yeah, i start getting a sense of the challenge. for instance an instruction can't hold some constant to add to some other cell. it has to actually apply the operations on memory. is that kinda it?
00:02:10 <ais523> and then just simulates the remaining loop executions until something tests as zero
00:02:37 <ais523> this is enough to optimise code that implements a divmod into an actual divmod instruction
00:02:56 <ais523> and divmod is one of the most important operations when using a single tape cell to store arbitrary amounts of data, because it lets you use it like a stack
00:03:17 <ais523> (you hold the stack in the digits of the number, the top of the stack is the least significant digit, then you divmod to pop and multiply-add to push)
00:04:22 <avih> i sort of get the very rough idea of what you're saying, but really not more than that :/
00:04:50 <avih> (but i'm definitely missing background here)
00:06:05 <ais523> actually this reminds me of the discussion on literate programming above
00:06:21 <ais523> literate programming isn't a huge change to what you can do, but it's expected to be combined with a particular programming style
00:06:29 <avih> and when i think about it, i'm not even sure where i'd start optimizing bignum bf, because except trivial constants, an instruction can't include them...
00:06:41 <ais523> bignum BF is similar, it doesn't hugely change programs written for wrapping interpreters, but it adds new possibilities which have their own style
00:06:59 <ais523> (and bignum BF is often run on very short tapes – three cells is enough)
00:07:17 <avih> yeah, i do get the extra dimension it adds, quite literally
00:07:43 <b_jonas> avih: I assume you'd optimize all loops that have no inner loop and are balanced
00:07:47 <avih> it's like every cells is its own infinite tape
00:07:59 <ais523> avih: yes, that's a good way to put it
00:08:28 <avih> b_jonas: yes. but that's trivial. teh next step is the interesting one.
00:08:57 <ais523> avih: have you seen the result that bignum brainfuck only needs two pairs of brackets (total, in the whole program) to be Turing-complete?
00:09:42 <avih> b_jonas: the 1k bf2c in sh which you saw does that too, in like 5 lines of awk.
00:09:44 <ais523> https://cs.stackexchange.com/questions/102363/how-many-pairs-of-brackets-are-sufficient-to-make-brainfuck-turing-complete
00:10:00 <esolangs> [[User talk:Sawyer.go0923]] https://esolangs.org/w/index.php?diff=168529&oldid=168497 * Sawyer.go0923 * (+61)
00:10:02 <ais523> this sort of thing is why optimising nested loops is in general very hard
00:10:37 <avih> ais523: no. but i do get a sense of why that can be true
00:10:57 <ais523> I'm not sure how many you need for 1-bit or 8-bit BF
00:10:57 <avih> (even if not the specifics)
00:11:47 <esolangs> [[User talk:Sawyer.go0923]] https://esolangs.org/w/index.php?diff=168530&oldid=168529 * Sawyer.go0923 * (-2)
00:12:26 <esolangs> [[User talk:Sawyer.go0923]] https://esolangs.org/w/index.php?diff=168531&oldid=168530 * Sawyer.go0923 * (+35)
00:12:34 <avih> ais523: in general absolutely yes, but practically in many cases, as long as all the loops are balanced, it doesn't feel beyond reach. but it does require more infrastructure for tracking states and deps
00:13:13 <avih> (re hard to optimize nesting loops)
00:13:17 <ais523> right, in the 2-bracket BF construction both loops are unbalanced (in different directions)
00:14:58 <avih> plain flat balanced loops can be done almost blindly. it really requires very little.
00:15:26 <avih> (i.e. counter loops, where it's balanced and head overall delta is 1 or -1)
00:16:50 <ais523> there is something called the "polynomial optimisation" which is used for nested balanced loops, but I'm not sure I fully understand it – I think it only works for some of them rather than all of them
00:17:02 <esolangs> [[!frjnrehrbwgyrigbyieurgbyfaerkhbvrwgtr.]] https://esolangs.org/w/index.php?diff=168532&oldid=168479 * Sawyer.go0923 * (+16)
00:20:00 <avih> ais523: i might have a sense of where it stops working - when the same cell is used cumulatively at multiple levels of nesting
00:20:14 <ais523> avih: that's my guess too
00:20:30 <avih> in some cases it should be solvable too, but i think not in all of them
00:21:51 <ais523> I think probably the case where it doesn't work is if the inner loop changes the outer loop's control cell
00:21:56 <avih> because the nesting scenario doesn't flat out unroll it - it turns it into an an "if", which is great speedup, but hard to optimize over multiple levels
00:22:58 <avih> (no pun intended in "flat out")
00:23:07 <avih> (well, maybe just a little)
00:24:03 <avih> ais523: yeah, that definitely wouldn't work with a "naive" optimizer for this construct, but if it can track the values and still "get" the over delta, it might
00:26:11 <ais523> hmm, I think balanced-loop-only bignum BF is TC, because I think you can compile Brainpocalypse II to it, but I haven't worked out the details of the compile so maybe I'm missing something important
00:26:13 <avih> but an optimizer doesn't have to optimize everything. if whatever it optimizes is effective, at reasonable cost, then it's still worth it
00:27:34 <b_jonas> one thing that could be hard to optimized is if a conditional is implemented as unbalanced like [BODY >]< where the right square bracket is on a cell that's always zero but you can only tell that from global analysis
00:27:39 <ais523> it's still interesting to figure out the point at which an optimizer *can't* be written, though, as it helps to know what can be
00:27:51 <b_jonas> as opposed to, say, [BODY >[-]]<
00:28:00 <ais523> b_jonas: that's actually the thing that made me give up trying to write a BF optimizer myself
00:28:23 <ais523> trying to figure out global invariatns
00:28:27 <avih> b_jonas: that _should_ be optimizable if the optimizer keeps track of known cell values, at least to some degree
00:29:19 <avih> (depending which barriers make it drop its knowledge)
00:30:12 <b_jonas> avih: yes, but it needs to simultaneously optimize conditionals to figure out that this [BODY>]< is balanced and figure out global invariants, because those two can circularly depend on each other
00:30:40 <ais523> global invariants circularly depend on themselves, it's a pain
00:31:17 <b_jonas> I don't want to write a brainfuck optimizer, but that sort of thing can come up in less esoteric optimizers too
00:31:20 <esolangs> [[User talk:Sawyer.go0923]] https://esolangs.org/w/index.php?diff=168533&oldid=168531 * Aadenboy * (+478) add note
00:31:23 <avih> yes. it depends a lot on the specifics. but in my mind, there's a maximum body of knowledge that an optimizer can keep track of (without actually running the code), and if some constructs are deducable from this knowledge, then it's optimizable
00:33:25 <ais523> there's also the JIT approach: you guess at a global invariant, and produce code that runs assuming the invariant (while checking it's true), and if the invariant ever becomes false, it recompiles itself without the invariant
00:33:40 <ais523> (this can save time even if the invariant isn't always true, as long as it's usually true)
00:34:12 <ais523> and I guess a variant of that where you codegen two versions, one which assumes the invariant and one that doesn't, and jump back and forth based on whether it's true or false at the time
00:34:26 <avih> ais523: how do you prevent it from running indefinitely? setting some hardcoded limit on the instructions executed or some such?
00:34:40 <ais523> avih: prevent what from running indefinitely? the program or the optimiser?
00:34:52 <avih> the hit to test the hypothesis
00:35:10 <ais523> avih: so you run it while the program is running
00:35:17 <ais523> and monitor what the program actually does
00:35:34 <ais523> i.e. you aren't trying to predict the program's behaviour in advance, you monitor it at runtime instead
00:35:53 <avih> how do you know that if you hit head 1000 times, the next coin flip won't be tail?
00:35:55 <ais523> this means that the running program has to recompile itself if you guessed wrong, so the program and the compiler are kind-of looped into each other
00:36:07 <ais523> avih: you don't, but you've simulated the program with 1000 heads
00:36:25 <ais523> and if it eventually hits tails, you still have the state of the program after 1000 coinflips to start from
00:36:36 <ais523> so you recompile a version that doesn't assume heads but continue it where it left off
00:36:42 <avih> not sure i get it then. how does it optimize then, if it only runs with the program?
00:37:01 <ais523> the optimizer runs while the program is running rather than beforehand
00:37:17 <ais523> so it has to be able to change what code is running while it's running
00:37:18 <avih> still, what can it tell about the future?
00:37:25 <ais523> it doens't have to, it just has to check
00:37:43 <ais523> like, say after 10 heads, it thinks "I should generate code that assumes heads because it'll run faster while this run of heads continues"
00:37:47 <avih> i must be missing something. let me read that jit thing more carefully. sec.
00:38:02 <ais523> then after another 990 heads, it finds out that it was wrong – but that doesn't matter because it still ran 990 coinflips at high spee
00:38:13 <ais523> which is faster than using the unoptimised version for all 1000
00:38:17 <avih> so basically modern cpu branch prediction?
00:38:29 <avih> why didn't you say that? :)
00:38:38 <avih> (i did think about it too in the past)
00:38:48 <ais523> because I didn't realise it was an analogy that would help (and didn't realise it was an analogy until you pointed it out)
00:39:26 <ais523> speculative execution in current CPUs does seem to be best viewed as though it were a type of JIT
00:39:43 <esolangs> [[User talk:Sawyer.go0923]] https://esolangs.org/w/index.php?diff=168534&oldid=168533 * Sawyer.go0923 * (+148)
00:39:50 <avih> i thought you'd use jit to check which future is the correct one, but probability based, sure, it should work
00:42:26 <avih> in a way, one of the reasons my optimizing interpreter is so much faster even from others which basically do the same shtick (plain balanced loops), is because my main loop is optimized according to the instructions probabilities (cascading if-else tree), rather switch/case over the instructions. this ends up basically 2x faster almost always
00:44:09 <avih> the interesting part is that i was sure that with switch/case, PGO would "get it" and optimize it at least as good as my manually constructed if-else tree, but far from it. not even close.
00:45:10 <ais523> I wonder how this compares to threaded code in terms of branch prediction efficiency?
00:45:24 <ais523> switch/case doesn't branch-predict well because all the branches are done from the same point
00:46:07 <ais523> "threaded code" is the name given for the technique where, at the end of the equivalent of each case…break of a switch, you use a separate technique for branching to the correct label from there
00:46:24 <ais523> (which in practice usually seems to be a computed goto, although if-trees probably also work)
00:46:40 <ais523> that way the branch predictor learns which branches tend to follow which other branches, rather than which branch is the most common overall
00:46:48 <ais523> I've never tried it but I've heard good things about it
00:46:51 <avih> i understand. i don't know. i think a combination of both would get the advantage of both?
00:46:58 <esolangs> [[Luau]] N https://esolangs.org/w/index.php?oldid=168535 * Sawyer.go0923 * (+426) Created page with "Luau is not an esoteric programming language. To check it out, go to the [https://en.wikipedia.org/wiki/Luau_(programming_language) Wikipedia page] or [https://luau.org luau website]. ==See also== * [https://en.wikipedia.org/wiki/Luau_(programming_language) Luau] * [[
00:48:11 <avih> but it _really_ surprised me that PGO over a single switch was nowhere near if-else tree. like, really.
00:49:07 <ais523> PGO is probably just checking the probabilities of each case of the switch, and if all of them are below 50%, it probably didn't change the codegen at all
00:49:24 <avih> and the switch was as "optimized" as it can be for PGO to assess it correctly. less than 10 cases, all of them small and end in "break", sequential values starting at 0, basically everything it could want was there, but in the end, really nowhere near.
00:49:49 <ais523> hmm, maybe the compiler is better at jump-threading the if-else tree than it is at jump-threading the switch
00:50:48 <avih> sec, let me show you the approaches.
00:51:05 <ais523> this came up in Rust, the "match in a loop" method of implementing the equivalent of a computed goto is the best option Rust has atm, but it optimises poorly, and apparently that's because LLVM can't jump-thread properly through a match/switch in a loop (which is apparently because, although the code for that exists, it's too slow to turn on by default)
00:51:11 <int-e> ais523: I'm afraid to ask what multi-threaded code might be then (scnr)
00:51:26 <ais523> int-e: this is an unfortunate clash of names
00:51:49 <int-e> we're so bad at terminology (we = humanity, collectively)
00:52:27 <ais523> I like trying to do simplifications that cross multiple levels of abstraction, but they are often hard to talk about because different levels use the same term to mean different things
00:53:34 <avih> https://0.vern.cc/B.txt
00:53:46 <ais523> "capability" has been coming up quite a bit recently, it means three different things that are relevant to the things I'm trying to reason about (and a fourth that isn't directly relevant but could be)
00:54:24 <ais523> avih: right, this is probably an issue with jump threading
00:54:57 <ais523> actually no, the compiler isn't likely to be looking at *pc
00:55:03 <ais523> so jump threading wouldn't help
00:55:43 <avih> i would think it just needs to find out the probabilities of each case.
00:56:23 <ais523> you might want to look at the machine code to see how it differs
00:56:36 <avih> i ran few bf programs, big and small, and noticed that the probabilities, at least with my instructions set, are largely similar
00:56:49 <ais523> I don't think PGO would help the switch/case much because it's likely to compile into the same jump table regardless of the probabiities, unless they're extremely skewed
00:57:15 <avih> so that's how i constructed my if-else tree. it could differ with others though. e.g. in my case ADD also does zero.
00:58:00 <ais523> now I'm wondering how much work a truly branchless BF interpreter would be
00:58:19 <avih> ais523: yeah, i did want to check what it generates, but didn't get to that yet. but suffice is to say that neither gcc not clang got anywhere near with PGO. but clang got closer than gcc.
00:59:17 <avih> ais523: surely it would not be possible?
00:59:39 <avih> well.. i think it would not be possible
00:59:58 <ais523> it should definitely be possible (except for I/O which doesn't really need optimising because it's so slow naturally), a non-optimizing interpreter could represent each opcode by amount to add to current tape element, amount to add to tape pointer, amount to add to instruction pointer if current tape element is nonzero
01:00:15 <ais523> that only contains one "if" which could be replaced by a conditional select
01:00:19 <avih> but it is one of the things my code tries to minimize. almost no branching inside each of the instructions code do_XXX
01:00:50 <avih> like, input checks for EOF, but that's almost it.
01:00:50 <esolangs> [[ErrorFull]] https://esolangs.org/w/index.php?diff=168536&oldid=146279 * Sawyer.go0923 * (+400)
01:01:15 <ais523> your , and . will have a lot of branches inside the standard library routines you call into to do the I/O
01:01:24 <avih> the code which runs the most if by far the instructions selector
01:02:17 <avih> sure, but that's out of my control, at least until (if) i merge consecutive outputs into one
01:02:42 <avih> i did try that btw. implement line buffer inside the interpreter. nearly zero impact.
01:02:58 <ais523> , and . don't run often enough to need optimising
01:03:04 <avih> well, not even nearly. i couldn't measure a diff.
01:03:24 <avih> exactly. they're not the bottleneck.
01:04:01 <ais523> programming for when I/O is the bottleneck is really weird and significantly different from normal programming
01:04:36 <ais523> so I wouldn't worry about trying to micro-optimize I/O too much, when it's worth it your whole program changes
01:04:57 <avih> so to get the fastest, it needs to minimize the code and branching to reach the next instruction code. and the if-else tree does part of it, the fact that the main loop doesn't have a stop condition is another (a specific instruction stops it - not testing the stop condition on every instruction)
01:05:44 <ais523> I think that's almost equivalent, the advantage to the specific instruction is that it can be on the inside of the if-else tree rather than the outside
01:06:15 <avih> exactly. branch prediction makes it slow, but who cares
01:07:10 <avih> but i didn't actually check a loop of: for (; is_exit; pc++). from the initial version my main loop was without a stop condition.
01:08:19 <ais523> <ais523> it means three different things ← in case someone in the logs asks, I'll give the answer pre-emptively in advance: capability bits of a pointer that specify the range it can access; object-capabilities; "capability passing style" in which the ability to do exclusive access to a piece of memory is passed into a function and returned from that function rather than being borrowed; and the fourth is Linux capabilities which split up the various
01:08:42 -!- ais523 has quit (Quit: quit).
01:23:29 <esolangs> [[WORST]] N https://esolangs.org/w/index.php?oldid=168537 * Sawyer.go0923 * (+6129) Created page with "{{Infobox language | name = WORST | year = 2025 | designer = User:Creator | website = | paradigm = Esoteric, intentionally hostile | license = Public domain }} '''WORST''' is an esoteric programming language designed to be as unpleasant, counter-intuitive, and err
01:35:20 <esolangs> [[WORST]] https://esolangs.org/w/index.php?diff=168538&oldid=168537 * Sawyer.go0923 * (-162)
01:52:08 <esolangs> [[Esolang talk:Community portal]] https://esolangs.org/w/index.php?diff=168539&oldid=166844 * NTMDev * (+40)
01:52:20 <esolangs> [[Esolang talk:Community portal]] https://esolangs.org/w/index.php?diff=168540&oldid=168539 * NTMDev * (+17) /* Discord */
01:57:40 <esolangs> [[Esolang talk:Community portal]] https://esolangs.org/w/index.php?diff=168541&oldid=168540 * Aadenboy * (+331)
02:21:08 -!- simcop2387 has joined.
02:25:10 -!- perlbot has joined.
02:32:37 -!- 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:42:37 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168542&oldid=168527 * NTMDev * (+507) /* sort */
02:44:11 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168543&oldid=168542 * NTMDev * (+89) /* String Checkers */
02:44:43 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168544&oldid=168543 * NTMDev * (+56) /* String Checkers */
02:48:35 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168545&oldid=168544 * NTMDev * (+482) /* String Checkers */
02:52:14 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168546&oldid=168545 * NTMDev * (+158)
04:15:30 <esolangs> [[Resubmit]] https://esolangs.org/w/index.php?diff=168547&oldid=168237 * Yayimhere2(school) * (+86) /* Semantics */
04:15:46 <esolangs> [[Resubmit]] https://esolangs.org/w/index.php?diff=168548&oldid=168547 * Yayimhere2(school) * (-6) /* Semantics */
04:37:40 -!- b_jonas has quit (Ping timeout: 256 seconds).
04:37:55 <esolangs> [[Bitty]] https://esolangs.org/w/index.php?diff=168549&oldid=168192 * Nomnomnom * (+159) added comptational class
05:23:05 -!- impomatic has quit (Ping timeout: 250 seconds).
05:53:22 -!- int-e_ has joined.
05:53:36 -!- op_4_ has joined.
05:54:17 -!- pool2 has joined.
05:56:41 -!- pool has quit (Ping timeout: 256 seconds).
05:56:41 -!- perlbot has quit (Ping timeout: 256 seconds).
05:56:41 -!- int-e has quit (Ping timeout: 256 seconds).
05:56:41 -!- op_4 has quit (Ping timeout: 256 seconds).
05:56:41 -!- slavfox has quit (Ping timeout: 256 seconds).
05:56:41 -!- pool2 has changed nick to pool.
05:56:43 -!- op_4_ has changed nick to op_4.
05:56:43 -!- Melvar has quit (Ping timeout: 256 seconds).
05:58:15 -!- slavfox has joined.
05:59:23 -!- perlbot has joined.
06:10:31 -!- Melvar has joined.
06:22:05 -!- pool has quit (Read error: Connection reset by peer).
06:24:12 -!- pool has joined.
06:38:27 -!- impomatic has joined.
06:47:00 <esolangs> [[Sorted!]] https://esolangs.org/w/index.php?diff=168550&oldid=38970 * Tpaefawzen * (+84) /* External resources */ +1
06:59:52 <esolangs> [[JUSTIF]] https://esolangs.org/w/index.php?diff=168551&oldid=91381 * Tpaefawzen * (+58) /* External resources */ +1
07:53:01 <esolangs> [[Vixen]] https://esolangs.org/w/index.php?diff=168552&oldid=166918 * Corbin * (+5) /* Core */ Clean up quotation marks.
07:58:48 <esolangs> [[Vixen]] https://esolangs.org/w/index.php?diff=168553&oldid=168552 * Corbin * (+401) /* Objects */ More precisely explain parents and delegation as well as the asterisk convention.
08:06:57 -!- impomatic has quit (Quit: Client closed).
08:10:56 <esolangs> [[Vixen]] M https://esolangs.org/w/index.php?diff=168554&oldid=168553 * Corbin * (+0) /* Cloning */ Fix flag to execlineb. Yes, it almost doesn't matter. Yes, it can be the cause of subtle bugs when chaining calls.
08:26:21 -!- Sgeo has quit (Read error: Connection reset by peer).
08:31:27 -!- tromp has joined.
09:45:09 -!- Taneb has joined.
10:33:52 -!- impomatic has joined.
10:51:32 <esolangs> [[Contains everything]] https://esolangs.org/w/index.php?diff=168555&oldid=168451 * C++DSUCKER * (+40) I changed my mind, the langauge should no longer be allowed to be recursive. i wil add a finite recursion operator.
10:53:21 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
10:55:02 <esolangs> [[Contains everything]] https://esolangs.org/w/index.php?diff=168556&oldid=168555 * C++DSUCKER * (+9)
11:02:01 -!- tromp has joined.
11:15:53 -!- impomatic has quit (Quit: Client closed).
11:34:29 -!- int-e_ has changed nick to int-e.
11:53:42 -!- Everything has joined.
12:32:21 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:36:27 -!- Taneb has quit (Ping timeout: 252 seconds).
12:44:04 -!- Taneb has joined.
12:48:46 -!- tromp has joined.
13:18:32 <avih> int-e: i managed to improve my COND (==1) so that: 1. one '-' and one '+' instead of two of each. 2. restore the original value before entering the COND block. 1/2 combined is less complex (easier to document) and less moves/instructions (-4 chars). i think i'm now reasonably happy with it (bottom version). i said i really like your "one COND" approach... https://0x0.st/KfTu.txt
13:22:43 -!- pool has quit (Read error: Connection reset by peer).
13:23:10 -!- pool has joined.
13:31:31 -!- ais523 has joined.
13:38:58 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
14:05:55 -!- tromp has joined.
14:22:34 -!- impomatic has joined.
14:26:55 -!- impomatic has quit (Ping timeout: 250 seconds).
14:44:02 <esolangs> [[Luau]] https://esolangs.org/w/index.php?diff=168557&oldid=168535 * Sawyer.go0923 * (+4)
15:06:24 -!- Taneb has quit (Ping timeout: 244 seconds).
15:16:53 -!- wob_jonas has joined.
15:22:53 -!- pool has quit (Read error: Connection reset by peer).
15:23:11 <wob_jonas> ais523: re match in a loop optimizes badly, that sounds omnious because I want to compile Enchain into C (or C++) switch in a loop. this works better in C than in Rust because C switch has fallthrough between a cases, so when the Enchain code has a conditional jump it compiles to setting a variable to the target then a conditional break.
15:24:56 -!- pool has joined.
15:32:21 <wob_jonas> normally you'd just compile into if{goto} in C. I was thinking of a switch because for some reason I put it into my head that I want to allow nested functions and that you should be able to goto out from a function, so when that happens the compiled C function would return an integer telling the label to jump to, or zero to continue execution
15:32:22 <wob_jonas> normally. this is almost certainly a bad idea, I shouldn't do it, I don't think my original motivation for it is valid, and even if I do allow it it would be easier to just add a small switch{goto} at every call side of such a function, because most nested functions that you write in practice will have only very few jump targets.
15:35:30 <ais523> wob_jonas: you can avoid the performance penalty by manually using gotos between the switch arms rather than going round the loop
15:35:43 <ais523> even if the switch and loop exist, nothing forces you to use them, you can just goto instead
15:36:42 <wob_jonas> exactly, and I shouldn't use the looped switch at all, I should just compile to goto, if{goto}, switch{goto} in C.
15:37:09 <wob_jonas> if I don't use the case labels then I don't need the switch in first place
15:38:16 -!- wob_jonas has quit (Quit: Client closed).
15:38:29 -!- wob_jonas has joined.
15:38:52 <wob_jonas> the switch would be needed if I allowed jumps with runtime-computed targets, which I probably could do but probably shouldn't do. I should make all label values compile-time constants.
15:39:11 <wob_jonas> I mean all label values in Enchain compile-time consants.
15:40:17 <wob_jonas> ok, so then the big looped switch for the whole function body is just a bad idea that I confused myself into
15:40:38 <ais523> fwiw I don't know why compilers find it hard to optimise a loop-switch where an arm specifies a value for the switch constant on the next iteration into a direct goto between branches
15:40:58 <ais523> I've been told it's hard to get that particular optimisation to run efficiently, but don't know why
15:46:32 <wob_jonas> ais523: I was told that rust doesn't have a goto built-in because it would be hard to teach the old lifetime checker to handle it correctly, but the old lifetime checker isn't even around anymore so I'm not sure that applies. But at least even if goto is easy to compile in C, if you want to compile it in C++ the compiler has to figure out which
15:46:32 <wob_jonas> local variables to destroy (and prove that no local variables have to be initialized, that would be a compile error). I imagine there might be a similar but harder problem in rust, because in general the compiler has to update the initialized flags for all local variables, and it's very important that the compiler understands the control flow well
15:46:33 <wob_jonas> enough that it can completely optimize out initialized flags or their updates almost all the time.
15:47:25 <ais523> the current plans for Rust is to have some way to mark the end of a branch of a loop-switch to say that it's actually meant to be compiled as a goto
15:48:16 <ais523> so that all the borrow checking, drop flags, etc. can be done on the loop-match and then all that changes is the code generation
15:48:45 <wob_jonas> oh yeah, "drop flags" is what they're called
15:55:27 <wob_jonas> ais523: I don't think that works. I thought the problem was that the liveness checker needs to understand goto to understand arbitrary control flow involving goto, because if it's phrased as loop-switch then the necessary information is hidden in some state variable of whose value the liveness checker doesn't need to track.
15:56:08 <ais523> wob_jonas: well there may be false positives (i.e. programs that would be sound but are rejected) doing it this way, but that doesn't create any soundness holes
15:56:57 <wob_jonas> but then couldn't it also create cases when the compiler doesn't optimize away drop flags properly for the same reason?
15:58:17 <ais523> wob_jonas: possibly but I don't think that's seen as an issue
15:59:08 <wob_jonas> since gotos and conditional gotos (as well as function calls and function returns) are the main form of control flow in Enchain, I want the typechecker to understand the control flow, as in for each point statement I want to know what the next statement executed after it can be. this is why I shouldn't have computed gotos (or function pointers),
15:59:08 <wob_jonas> those make the control flow almost impossible to follow.
16:00:08 <wob_jonas> and the control flow graph seems an easier abstraction to understand than the high-level control structures like if/while anyway
16:09:20 -!- wob_jonas has quit (Quit: Client closed).
16:23:02 -!- pool has quit (Read error: Connection reset by peer).
16:24:15 <esolangs> [[Iterate/Math]] https://esolangs.org/w/index.php?diff=168558&oldid=168500 * Aadenboy * (-425) turning these into modules
16:24:57 -!- pool has joined.
16:28:55 <esolangs> [[!frjnrehrbwgyrigbyieurgbyfaerkhbvrwgtr.]] https://esolangs.org/w/index.php?diff=168559&oldid=168532 * Yayimhere2(school) * (+5) correct comp class
16:29:22 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
16:31:28 -!- Lord_of_Life has joined.
16:33:14 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168560&oldid=168546 * NTMDev * (-5) /* = */
16:40:59 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=168561&oldid=168560 * NTMDev * (+833) /* String Operations 2 */
16:44:42 -!- pool has quit (Ping timeout: 256 seconds).
16:53:20 -!- pool has joined.
16:58:37 -!- impomatic has joined.
17:26:06 <esolangs> [[Iterate/Math]] https://esolangs.org/w/index.php?diff=168562&oldid=168558 * Aadenboy * (-727) fixes
17:36:32 -!- impomatic has quit (Quit: Client closed).
17:47:30 -!- amby has joined.
17:51:22 -!- impomatic has joined.
17:55:12 -!- sytra has joined.
18:25:03 <esolangs> [[Iterate/Compilation]] https://esolangs.org/w/index.php?diff=168563&oldid=168510 * Aadenboy * (+518) extra
18:28:04 -!- b_jonas has joined.
18:31:24 <b_jonas> ok, so there's a big problme with what I thought about Enchain gotos. we can't just have labels behave as zero-sized values whose types encode their label, because then figuring out the possible control flow and typechecking would mutually depend on each other. there are restricted versions of this that could work, but I have to figure out which, if any, are checkable at compile time, expressive enough,
18:31:30 <b_jonas> and don't feel kludgey like labels are completely unrelated to names. thank you #esolangs in the role of rubber duck.
18:43:31 -!- amby has quit (Read error: Connection reset by peer).
19:06:30 -!- impomatic49 has joined.
19:06:35 -!- amby has joined.
19:08:09 -!- impomatic has quit (Ping timeout: 250 seconds).
19:15:26 -!- tromp has quit (Read error: Connection reset by peer).
19:23:18 -!- pool has quit (Read error: Connection reset by peer).
19:23:42 -!- pool has joined.
19:35:47 -!- sytra has quit (Quit: sytra).
19:54:19 -!- sytra has joined.
20:00:13 <esolangs> [[Iterate/Math]] https://esolangs.org/w/index.php?diff=168564&oldid=168562 * Aadenboy * (+547) /* Logic */
20:23:24 -!- pool has quit (Read error: Connection reset by peer).
20:23:42 -!- pool has joined.
20:37:54 -!- impomatic49 has quit (Quit: Client closed).
20:38:25 -!- Everything has quit (Quit: Lost terminal).
20:40:44 <esolangs> [[G Sharp]] M https://esolangs.org/w/index.php?diff=168565&oldid=154461 * Ractangle * (-54) /* Functions */
20:41:28 <esolangs> [[G Sharp]] https://esolangs.org/w/index.php?diff=168566&oldid=168565 * Ractangle * (-5) /* Truth-machine */
20:42:38 <esolangs> [[Iterate/Math]] https://esolangs.org/w/index.php?diff=168567&oldid=168564 * Aadenboy * (+430)
20:42:52 <esolangs> [[Iterate/Math]] M https://esolangs.org/w/index.php?diff=168568&oldid=168567 * Aadenboy * (+2) /* Minimum/maximum of A and B */ h3
20:45:23 <esolangs> [[G Sharp]] M https://esolangs.org/w/index.php?diff=168569&oldid=168566 * Ractangle * (+260) /* Functions */
20:47:23 <esolangs> [[True (Ractangle)]] M https://esolangs.org/w/index.php?diff=168570&oldid=163114 * Ractangle * (-149) /* Infinite loop */
20:48:23 <esolangs> [[GTA6]] M https://esolangs.org/w/index.php?diff=168571&oldid=168481 * Ractangle * (-1)
21:21:37 -!- impomatic has joined.
21:37:37 <APic> Good Night * 😴
21:43:45 -!- JAA has changed nick to jinn7.
21:43:59 -!- jinn7 has changed nick to JAA.
21:58:49 -!- ais523 has quit (Quit: quit).
22:05:19 <esolangs> [[Iterate/Math]] https://esolangs.org/w/index.php?diff=168572&oldid=168568 * Aadenboy * (+221) /* If else */
22:09:40 -!- sytra has quit (Remote host closed the connection).
22:12:45 -!- impomatic has quit (Quit: Client closed).
22:36:57 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=168573&oldid=168512 * Buckets * (+13)
22:37:53 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=168574&oldid=168513 * Buckets * (+14)
22:38:12 <esolangs> [[BeeJazz]] N https://esolangs.org/w/index.php?oldid=168575 * Buckets * (+1783) Created page with "BeeJazz is an Esoteric Programming language created By [[User:Buckets]] in 2020, after They watched [https://en.wikipedia.org/wiki/Bee_Movie / A Certain Movie featuring bees And jazz.] {| class="wikitable" |- ! Commands !! Instructions |- | B || Assign The current hexe
22:38:33 <esolangs> [[BeeJazz]] M https://esolangs.org/w/index.php?diff=168576&oldid=168575 * Buckets * (-2)
22:39:00 <esolangs> [[110010000100110110010]] https://esolangs.org/w/index.php?diff=168577&oldid=147808 * Kaveh Yousefi * (+614) Added a hyperlink to my implementation of the 110010000100110110010 programming language on GitHub and altered the Unimplemented tag to Implemented.
22:44:58 -!- DOS_User_webchat has joined.
23:10:18 -!- pool has quit (Read error: Connection reset by peer).
23:10:41 -!- pool has joined.
23:13:03 -!- DOS_User_webchat has quit (Remote host closed the connection).
23:15:48 -!- pool has quit (Read error: Connection reset by peer).
23:15:55 -!- pool6 has joined.
23:30:42 -!- Sgeo has joined.
23:47:25 <avih> int-e: "if (==0) BODY":
23:47:25 <avih> int-e (3 tmps): >+<[>->]>[>>]<<[-< BODY >]<
23:47:25 <avih> avih (2 tmps): >+<[>-]>[-< BODY >>]<<
23:50:08 <avih> and this can also be used with your 1-COND while loop, resulting in much much shorter code, which can still be used as a generic template (in my case COND is (==1), which does need 2 '-' and 2 '+')
23:51:03 <avih> (i do need both "if (==0) BODY" and "while (==1) BODY")
23:56:24 <avih> the "trick" to use only 2 tmps is that the BODY "if" is also unbalanced.
23:57:42 <avih> well, both have 2 unbalanced while/end, but with two tmps the other one is instead together with BODY.