2023-06-07 02:04:22 <veltas      > KipIngram: Hard to say about quantum, we don't know how small they will be able to machine it, and how relevant it will be to a small form factor for e.g. small companies or whatever
2023-06-07 02:04:47 <veltas      > And also making it smaller will probably make it faster so there's an inherent reason to go small anyway
2023-06-07 02:05:21 <veltas      > But will it ever be 'priced' for the general consumer? It depends what applications appear that consumers could be 'sold' on it with
2023-06-07 02:05:41 <veltas      > Right now it doesn't seem like there are any, but that was the case for general computing 80 years ago
2023-06-07 02:19:43 <veltas      > I mean we've already got consumers playing with AI tech
2023-06-07 02:19:51 <veltas      > It's good for that
2023-06-07 02:20:06 <veltas      > for that  fort hat  forth at
2023-06-07 08:02:02 <KipIngram   > Right - given the current situation, I'll just be surprised if they become "commonplace."  Never say never, but that would require a major breakthrough - we don't get there by just "refining our processes."
2023-06-07 08:02:09 <KipIngram   > Existing processes, that is.
2023-06-07 08:02:16 <KipIngram   > Needs something revolutionary.
2023-06-07 08:02:22 <KipIngram   > Which can happen, of course.
2023-06-07 08:03:16 <KipIngram   > I don't think I would say we're even to the ENIAC stage of quantum computer development.  Maybe one could say we are - I guess its debatable.
2023-06-07 08:03:39 <KipIngram   > I think we've done enough to prove that the concept itself actually does work.
2023-06-07 08:03:43 <KipIngram   > But not much more.
2023-06-07 08:05:17 <KipIngram   > Even that's really cool, though, because in some ways quantum computing feels almost like magic.
2023-06-07 08:05:30 <veltas      > I don't imagine major breakthrough, instead I imagine endless incremental improvements that heads in that direction
2023-06-07 08:06:16 <KipIngram   > Well, as I said, never say never.  That's just an awful lot of refinement.  Of course, I know we've done exactly that with standard computing.
2023-06-07 08:06:36 <KipIngram   > Even people that were at the top of the game in, say, the 1960's would likely never have predicted what we've done.
2023-06-07 08:06:48 <veltas      > I don't think there's any magic bullet. There are big hurdles like trying to produce something resembling a solid-state version of the lab conditions necessary for quantum computing to work
2023-06-07 08:06:55 <veltas      > But in between it's all refinement
2023-06-07 08:07:06 <KipIngram   > I think by the 1970's, though, a lot of people would have at least been open-minded to the idea.
2023-06-07 08:07:12 <KipIngram   > The writing was on the wall by then.
2023-06-07 08:07:38 <KipIngram   > Yes - that.  Getting a "chippable" approach.
2023-06-07 08:07:44 <KipIngram   > That's exactly what's required.
2023-06-07 08:08:08 <veltas      > Major extrapolation on my part comparing with progress of digital logic to semiconductors
2023-06-07 08:08:19 <veltas      > But it's what makes sense to my flat mind
2023-06-07 08:08:57 <KipIngram   > Also I think we need an approach that doesn't require major cooling.
2023-06-07 08:09:10 <KipIngram   > I think the most promising possibilities are these "topological" ones.
2023-06-07 08:09:23 <KipIngram   > They seem more robust against environmental perturbations.
2023-06-07 08:10:05 <KipIngram   > But if we do get "something revolutionary," my guess is it will be a different way of setting up qubits that just wins against the environment.
2023-06-07 08:10:14 <KipIngram   > Just swat that problem down completely somehow.
2023-06-07 08:10:25 <KipIngram   > Take it off the table altogether.
2023-06-07 08:11:09 <veltas      > I'm sure there's some theory about this already
2023-06-07 08:34:49 <KipIngram   > Yeah, there is work going on in that area.
2023-06-07 08:35:18 <KipIngram   > If we do wind up finding some "revolutionary" approach, then I think it will be very sudden.
2023-06-07 11:43:47 <veltas      > KipIngram: https://i.imgur.com/zc4HLVK.png
2023-06-07 14:44:51 <KipIngram   > This related to polymorphism in some way?
2023-06-07 14:45:25 <KipIngram   > Or is this an example from your system?
2023-06-07 16:42:00 <winduptoy   > I'm building a subroutine threaded forth on armv6-m and I'm trying to understand how to encode call instructions into new word definitions (compiled at runtime in a colon definition without the aid of an assembler). As I see it, I could either a) directly write a `bl` instruction, which requires me to calculate PC-relative addresses or b) do some gnarly `mov <#imm>`, shift, `mov <#imm>`, shift, etc. to build up the absolute address and finall
2023-06-07 16:42:01 <winduptoy   > with a `blx` instruction. Obviously if I wrote the full 32-bit address to memory and then `ldr`'ed it into a register and then branched, I'd be back at a direct threaded forth. Am I thinking about this the right way or missing something obvious? If someone can point to where this process happens in zeptoforth or coreforth I'm happy to dig in, I just couldn't grok either of them to figure this out.
2023-06-07 16:42:58 <KipIngram   > Usually in a subroutine threaded Forth each word that appears in a definition will result in a call instruction, and nothing else.
2023-06-07 16:43:32 <KipIngram   > That's the "starting point" -  you have the opportunity to "inline" short words if you choose to.  Like for 1+ you'd just inline an inc instruction on the register you're caching the top of stack in.
2023-06-07 16:44:13 <KipIngram   > Normally you'd do that by just going to the definition of 1+ and copy everything from the start up to but not including the "ret" instruction.
2023-06-07 16:44:30 <KipIngram   > Perhaps you have a bit in your headers that identifies words that should be inlined.
2023-06-07 16:44:53 <KipIngram   > Support for inlining is one of the biggest advantages of subroutine threrading.
2023-06-07 16:45:25 <KipIngram   > You can do something similar in other thread models by automatically constructing new primitives that are a sequence of existing primitives.
2023-06-07 16:46:04 <KipIngram   > If you're finding yourself thinking you need to do a bunch of bit shuffling then I'd think you're looking at something a little wrong.
2023-06-07 16:46:39 <KipIngram   > You also might inline any words that have code size below a certain level.
2023-06-07 16:47:55 <Zarutian_iPad> winduptoy: I have not looked at ARM ISA for a long while. Is that the only way to do subroutine calls? A Branch & Link eXtended?
2023-06-07 16:48:31 <winduptoy   > KipIngram: yeah I've got all that about inlining small words. I think my problem is that my instruction set doesn't have a simple `call` instruction, so I can't easily write the full 32-bit address and just jump there.
2023-06-07 16:49:33 <Zarutian_iPad> right. Because ARM wanted to be Position Independent codewise
2023-06-07 16:50:28 <winduptoy   > Zarutian_iPad: Yeah I can `bxl {register_name}` but getting the full 32-bit address into a register is what I can't wrap my mind around. If I store the address and then load it with a `ldr` instruction, then I've got a direct threaded forth because of the indirection, right?
2023-06-07 16:51:26 <winduptoy   > and `mov`ing into a register is limited to 8-bit immediate values on my platform
2023-06-07 16:51:59 <Zarutian_iPad> not nescisarily. You can look at it like the ldr and blx is just one instruction together so to speak
2023-06-07 16:52:36 <Zarutian_iPad> ldr r10, dest; blx r10, r15
2023-06-07 16:52:40 <Zarutian_iPad> or something
2023-06-07 16:54:11 <Zarutian_iPad> similiar how in EthereumVM bytecode an subroutine call is six bytes long and made up of instructions
2023-06-07 16:54:15 <MrMobius    > winduptoy: doesn't it have PC relative constant pools?
2023-06-07 16:54:27 <winduptoy   > so if I have to load those addresses from a list somewhere, I think that's exactly what this direct-threaded illustration shows: https://www.bradrodriguez.com/papers/mov1-2.gif
2023-06-07 16:54:28 <MrMobius    > also, what's wrong with the PC relative jump? seems to simplify things
2023-06-07 16:55:49 <Zarutian_iPad> if you need code denisty then you can have the subroutine call emitter subtract the absolute address of the destination from the location of the instruction
2023-06-07 16:56:27 <winduptoy   > MrMobius: the `bl` instruction requires PC-relative addresses and I'm not opposed to using it, I just wanted to make sure I wasn't unnecessariliy complicating things. Not sure what you mean by constant pool.
2023-06-07 16:57:32 <Zarutian_iPad> indirect pc relative immediate constant is the addressing mode used for constants pool use
2023-06-07 16:57:34 <MrMobius    > winduptoy: isn't there a form in the assembler like `ldr r10, =dest` or something like that?
2023-06-07 16:57:58 <MrMobius    > what Zarutian said
2023-06-07 16:58:28 <KipIngram   > Oh, I didn't catch on we were talking about constants.  Wouldn't you just create a  primitive for that that did a load immediate instruction?
2023-06-07 16:58:35 <KipIngram   > Note I've never written a code threaded system.
2023-06-07 16:59:37 <winduptoy   > MrMobius: oh yeah, but I'm trying to do this at runtime, so I won't have the luxury of the assembler creating constant pools.
2023-06-07 16:59:42 <Zarutian_iPad> KipIngram: I think the idea is to use aforesaid addressing mode to load and branch&link dest addresses
2023-06-07 17:00:17 <MrMobius    > winduptoy: right no assembler but you can do anything the assembler can. you might run into the problem of not knowing where to put the pool but it's something you can do
2023-06-07 17:00:40 <MrMobius    > zeptoforth just puts the pool down right in the code and puts a jump before it as I understand it
2023-06-07 17:01:00 <Zarutian_iPad> btw I do not like these kind of multi ops addressing modes
2023-06-07 17:02:38 <Zarutian_iPad> having to add the offset to the address of the instruction, then using the result to load the datum from memory, and then being able to use it
2023-06-07 17:03:14 <winduptoy   > MrMobius: Yeah I was hoping that my definitions (minus inlined stuff) would look equivalent to: `call x; call y; call z;` rather than something like `ldr r0, =word_pool; blx r0; ldr r0, =word_pool+1; blx r0; ldr r0, =word_pool+2; blx r0;` which seems like it would cause extra memory cache misses.
2023-06-07 17:03:28 <MrMobius    > no surprise. these types of ISAs are meant to work well for compilers not humans
2023-06-07 17:04:19 <MrMobius    > winduptoy: right. I'm not saying the constant pool is how you should do it. just saying it's functionality to be aware of
2023-06-07 17:05:47 <Zarutian_iPad> MrMobius: maybe compilers but definitly not logic circuitry that implements the ISA
2023-06-07 17:05:50 <KipIngram   > Bear in mind that if you do what I suggested (immediate load routines), then that would inline into just the push of the TOS register and that immediate load.
2023-06-07 17:06:07 <KipIngram   > That's for sure, Zarutian_iPad.
2023-06-07 17:06:27 <MrMobius    > Zarutian_iPad: so youre saying CISC > RISC?
2023-06-07 17:06:31 <KipIngram   > I remember when I first learned that Intel processors weren't really "hardware" anymore.  Blew my  mind.
2023-06-07 17:06:50 <KipIngram   > Made the complexity of the instruction set a lot easier to "see the feasibility of."
2023-06-07 17:07:06 <KipIngram   > I so, SO wish they would document and open that microcoding methodology.
2023-06-07 17:07:15 <KipIngram   > That's what I want to write - a Forth using THAT.
2023-06-07 17:07:31 <KipIngram   > Maybe someone will hack it one of these days.
2023-06-07 17:07:35 <Zarutian_iPad> MrMobious: nope, I am saying that something like excamera J1 or the canonical dual stackmachine ISA is much simpler to implement circuitrywise
2023-06-07 17:08:10 <Zarutian_iPad> the latter is from Koopmans book btw
2023-06-07 17:10:12 <Zarutian_iPad> in the case of FCPU-16, my own design, primitive instructions all have the uppermost three nybbles 0, if anyone of them are not then the instruction is a subroutine call to that address
2023-06-07 17:10:48 <Zarutian_iPad> a 16 bit cell system btw
2023-06-07 17:11:34 <Zarutian_iPad> sure a subroutine can not be in the first 16 locations of the address space but it is a small tradeoff
2023-06-07 17:13:16 <Zarutian_iPad> requires one big 12 input AND gate with inverted inputs
2023-06-07 17:15:41 <Zarutian_iPad> so, I would not call ARM nowdays RISC
2023-06-07 17:17:06 <KipIngram   > My own hardware desigs have come in two flavors - either 16 bit code words with the top bit distinguishing between calls vs. three 5-bit packed opcodes, or 32-bit code words with either six 5-bit or five 6-bit opcodes packed.  In the 32-bit case I have two top bits to play with - I usually do something like 1) opcodes, 2) call, 3) jump and 4) "something else" for the options there.
2023-06-07 17:17:24 <KipIngram   > Usually conditional jump for that fourth case.
2023-06-07 17:18:44 <KipIngram   > I generally wouldn't be going for "smallest" or "fastest," but instead some blend of those that happened to suit my fancy at the time.
2023-06-07 17:18:58 <Zarutian_iPad> KipIngram: Heard of IBM 360/370/390 condition codes?
2023-06-07 17:19:14 <KipIngram   > Long, LONG ago.
2023-06-07 17:19:21 <KipIngram   > Like 40 years ish.
2023-06-07 17:19:43 <KipIngram   > I don't remember much of it, but I had an interest in that architecture when I was in college.
2023-06-07 17:19:55 <Zarutian_iPad> yeah, here we have a fourway branching capability!
2023-06-07 17:20:03 <KipIngram   > Nice.
2023-06-07 17:20:39 <Zarutian_iPad> plus that ISA has an TRANSLATE instruction
2023-06-07 17:22:17 <Zarutian_iPad> is interruptable, takes four registers as it arguments
2023-06-07 17:23:13 <Zarutian_iPad> one for source pointer, one for destination pointer, one for bytecount, and one that points to a lookup table of 256 bytes
2023-06-07 17:24:22 <Zarutian_iPad> meant for EBDIC to ASCII and such translation but I saw an AES implemention use it to implement the S-boxes
2023-06-07 17:24:36 <KipIngram   > So I just wrote a test that uses a hundred million iterations to measure the time taken by my "next."  If one of these numbers was 100,000, it would mean next measured in at one nanosecond.  Here's the kind of variation I see:
2023-06-07 17:24:41 <KipIngram   > 20 samples
2023-06-07 17:24:43 <KipIngram   > 99363
2023-06-07 17:24:45 <KipIngram   > 94659
2023-06-07 17:24:47 <KipIngram   > 96761
2023-06-07 17:24:49 <KipIngram   > 137560
2023-06-07 17:24:51 <KipIngram   > 93968
2023-06-07 17:24:53 <KipIngram   > 96751
2023-06-07 17:24:55 <KipIngram   > 94866
2023-06-07 17:24:57 <KipIngram   > 107450
2023-06-07 17:24:59 <KipIngram   > 109327
2023-06-07 17:25:01 <KipIngram   > 92150
2023-06-07 17:25:03 <KipIngram   > 96329
2023-06-07 17:25:05 <KipIngram   > 90054
2023-06-07 17:25:07 <KipIngram   > 93151
2023-06-07 17:25:09 <KipIngram   > 103643
2023-06-07 17:25:11 <KipIngram   > 89468
2023-06-07 17:25:13 <KipIngram   > 105991
2023-06-07 17:25:15 <KipIngram   > 107918
2023-06-07 17:25:17 <KipIngram   > 117580
2023-06-07 17:25:19 <KipIngram   > 97839
2023-06-07 17:25:21 <KipIngram   > 103560  ok
2023-06-07 17:25:25 <Zarutian_iPad> blew my mind
2023-06-07 17:29:06 <KipIngram   > Oh, that does sound cool.
2023-06-07 17:38:04 <Zarutian_iPad> another is to use it to rearrange the sequence of 256 bytes by a template
2023-06-07 17:40:13 <Zarutian_iPad> so, I look at that TRANSLATE instruction in the same view as BLIT instructions/ops
2023-06-07 17:41:52 <Zarutian_iPad> and been thinking about how a similiar yet to be named instruction that uses a BitGrid tile instead of the lookup table
2023-06-07 17:42:55 <KipIngram   > :-)
2023-06-07 17:43:26 <KipIngram   > I think I'm just going to call that a 1 ns NEXT and leave it at that.
2023-06-07 17:43:42 <KipIngram   > Though I may like to figure out the standard deviation.
2023-06-07 17:44:02 <Zarutian_iPad> feed operand cells pointed by src to one side and take the result to dest from another, under control of the BitGrid via two bit signal
2023-06-07 17:44:16 <Zarutian_iPad> but just a thought
2023-06-07 18:40:40 <KipIngram   > The issue with constants (and variables) in code threading - that's one of the reasons it doesn't appeal a lot to me.  In code threading, you really need to make everything code.
2023-06-07 18:41:08 <KipIngram   > Constant -> immediate load, variable -> immediate load.
2023-06-07 18:41:19 <KipIngram   > What the thing really knows how to deal with is... subroutines.
2023-06-07 18:43:03 <KipIngram   > Then when we come to direct vs. indirect, what I see is that with direct you have to have code right there where the definition points.  So you either have to have a full copy of docol for every definition, or, if you don't, you have to have a jump instruction that takes you to it.  And there's the second jump - you wind up doing that indirection anyway.
2023-06-07 18:43:25 <KipIngram   > So unless you do put the whole docol in each place, I just don't see the point of direct instead of indirect.
2023-06-07 18:46:55 <veltas      > KipIngram: The picture is related to how I'm handling struct member names
2023-06-07 18:47:23 <veltas      > It's a screenshot of code from the language I've been designing on and off
2023-06-07 18:48:19 <unjust      > is that something in the realm of B or C--?
2023-06-07 18:48:32 <KipIngram   > It's interesting.
2023-06-07 18:48:53 <KipIngram   > That s[struct shape] is particularly interesting.
2023-06-07 18:50:29 <KipIngram   > So, anyway, I just wind up "coming back" to indirect threading over and over - I don't really feel like I lose anything very significant with it.
2023-06-07 18:50:39 <KipIngram   > And it's just so damn elegant.
2023-06-07 18:52:22 <Zarutian_iPad> KipIngram: in zeForth on FCPU-16 (VAR) and (CONST) in var and const definitions are subroutine-calls to : (VAR) R> ; and : (CONST) R> @ ; respectively
2023-06-07 18:53:36 <KipIngram   > How do you get back to your caller?
2023-06-07 18:54:24 <Zarutian_iPad> the normal EXIT that ; puts on the end
2023-06-07 18:54:45 <KipIngram   > I'm not picturing it quite right.
2023-06-07 18:55:30 <veltas      > KipIngram: Yeah in the design "struct shape" evaluates to the 'length' of the struct, and also makes the struct's members 'current' to the function
2023-06-07 18:55:35 <veltas      > So full name isn't needed
2023-06-07 18:55:42 <Zarutian_iPad> so a CONST or VAR word just get called directly like any other word in a word definition using those
2023-06-07 18:56:07 <KipIngram   > You're executing along - say your IP is X.  You make this call.  X(next) goes onto the return stack.  In the routine you pop that and use it - it's gone.  Looks to me like the (;) would return you a level too far up.
2023-06-07 18:56:24 <veltas      > unjust: It's called New B or NewB, it's heavily inspired by B, meant as a typeless alternative to C
2023-06-07 18:56:38 <Zarutian_iPad> so (CONST) and (VAR) return to the caller of that constant or variable
2023-06-07 18:56:39 <KipIngram   > Oh, NewB - I LIKE IT.
2023-06-07 18:56:54 <veltas      > It's got some comfort features designed into it to make it more practical than original B, and it can handle byte addressed systems
2023-06-07 18:57:08 <KipIngram   > I'm not seeing that.  When you made the call that IP is gone, except for the copy you put on the return stack.
2023-06-07 18:57:13 <KipIngram   > And you took that off and did something with it.
2023-06-07 18:57:30 <KipIngram   > The next thing on the return stack is the code that called where we were to start with.
2023-06-07 18:57:33 <Zarutian_iPad> I see your confusion
2023-06-07 18:57:44 <KipIngram   > Yeah - it'll make sense in the end I'm sure.
2023-06-07 18:57:54 <KipIngram   > I'm just missing something.
2023-06-07 18:58:13 <KipIngram   > Looks to me like the return stack winds up down by one when you're through with all that.
2023-06-07 18:58:32 <KipIngram   > There must be an additional level of nesting.
2023-06-07 18:58:43 <KipIngram   > then it would make sense.
2023-06-07 18:58:48 <Zarutian_iPad> : CONST create ‘ (CONST) , , ;
2023-06-07 18:59:05 <KipIngram   > I think I am seeing now how it pretty much has to be, if that's g oing to work.
2023-06-07 18:59:15 <KipIngram   > I was just not picturing one level.
2023-06-07 18:59:28 <KipIngram   > : foo  ... constant ... ;
2023-06-07 18:59:41 <KipIngram   > So foo calls constant.  An address in foo goes onto the return stack.
2023-06-07 18:59:44 <Zarutian_iPad> so lets say I have 42 CONST A
2023-06-07 18:59:50 <unjust      > veltas: seen https://www.cs.tufts.edu/~nr/c--/extern/man2.pdf ? not exactly typeless but there's bitsN (ie. bits8, bits16, bits32, bits64) and bool
2023-06-07 18:59:56 <KipIngram   > Then the constant code does a subroutine call, which is immeditaely followed by the value.
2023-06-07 19:00:06 <KipIngram   > You use  THAT return address to fetch the value.
2023-06-07 19:00:19 <KipIngram   > And THEN the (;) takes you back not to the constant word but into foo.
2023-06-07 19:00:20 <Zarutian_iPad> and in foo (CONST) gets called and that address gets onto the return stack
2023-06-07 19:00:27 <KipIngram   > Yeah - got it now.
2023-06-07 19:00:31 <Zarutian_iPad> precisely
2023-06-07 19:02:01 <Zarutian_iPad> : (JMP) R> @ >R ; is another one for you to puzzle out
2023-06-07 19:02:25 <KipIngram   > That seems fairly straightforward.  Guess my minds in the mode now.
2023-06-07 19:02:43 <KipIngram   > I was trying to have that first subroutine call you mentioned by IN foo.
2023-06-07 19:03:40 <KipIngram   > But you've got an extra call in there, the purpose of which is to materialize the address you need on the return stack.
2023-06-07 19:04:51 <Zarutian_iPad> on other ISA like say 6502 a jsr DOCOL for colon words
2023-06-07 19:04:59 <Zarutian_iPad> yeb
2023-06-07 19:05:33 <KipIngram   > Where do you put your data?  Like let's say I wanted an array.
2023-06-07 19:05:55 <KipIngram   > Well, I guess this same idea works for that too.
2023-06-07 19:06:01 <Zarutian_iPad> but then on FCPU-16 I am aiming for small memory
2023-06-07 19:06:09 <KipIngram   > What you're kind of doing is sneaking a direct threaded structure into those.
2023-06-07 19:06:17 <KipIngram   > That just gets called.
2023-06-07 19:07:05 <Zarutian_iPad> pretty much
2023-06-07 19:08:10 <KipIngram   > So those can't be inlined?  Am I thinking that out right?
2023-06-07 19:09:16 <Zarutian_iPad> : (inlineCONST) R> DUP 1+ >R @ ;
2023-06-07 19:10:02 <Zarutian_iPad> better known as (LIT)
2023-06-07 19:10:24 <KipIngram   > :-)
2023-06-07 19:10:38 <KipIngram   > I'm not willing to put all that extra docol overhead in there.
2023-06-07 19:10:53 <KipIngram   > But, that's just a personal preference.
2023-06-07 19:11:01 <KipIngram   > My (lit) is machine code.
2023-06-07 19:11:02 <veltas      > unjust: Yeah C-- is in that LLVM arena of compiler frontend output, as a language it solves different problems
2023-06-07 19:11:25 <KipIngram   > Loads using IP and nudges IP.
2023-06-07 19:11:51 <Zarutian_iPad> KipIngram: beuty of having the inner address interpreter, so to speak, as your machine code.
2023-06-07 19:11:57 <veltas      > unjust: As you say it's not typeless. My goal with NewB is a very very minimal syntax, and to be typeless, while still being 'nice' and practical to program in
2023-06-07 19:12:43 <veltas      > And to get that feel of B which I think many people will enjoy if they try it
2023-06-07 19:12:50 <KipIngram   > I think it's a nice approach for trying to push toward less machine code overall.
2023-06-07 19:13:03 <KipIngram   > Showcases the Forth structure in a really nice way.
2023-06-07 19:14:45 <Zarutian_iPad> : (JMPTBL) R> 2DUP @ < IF 1+ + @ ELSE DUP @ + 1+ THEN >R ;
2023-06-07 19:16:00 <KipIngram   > It's no wonder you were sorting out that situation with COMPILE the other day - big chunks of your system operate around the same general idea.
2023-06-07 19:16:18 <KipIngram   > It's a zone you've played in a lot.
2023-06-07 19:20:07 <Zarutian_iPad> 
ACTION is rather proud of that little word definition

2023-06-07 19:20:12 <unjust      > veltas: i'm eager to try it when you're ready to share it with the public
2023-06-07 19:32:02 <KipIngram   > Zarutian_iPad: I think the whole general reasoning is elegant and nice.
2023-06-07 19:32:41 <KipIngram   > I would argue that you are approaching a maximum in "return stack exploitation."  :-)
2023-06-07 19:34:10 <thrig       > stacksploitation
2023-06-07 19:35:07 <KipIngram   > Indeed.  THAT is a good word.
2023-06-07 19:35:26 <KipIngram   > even has "stacks" instead of "stack" in it.