2023-06-08 06:08:52 <veltas      > Agreed that (JMPTBL) is a very nice def
2023-06-08 06:11:18 <veltas      > I don't deserve this random hacker who keeps giving me suggestions for improvements to zenv
2023-06-08 06:12:41 <veltas      > They literally optimised SWAP the other day, I am a bit dumb for failing to get it right the first time although I suppose I was less experienced when I first wrote it
2023-06-08 06:14:42 <veltas      > https://github.com/Veltas/zenv/commit/7393715f6667ba04cca6b6dbf2c6a4783e7f3182
2023-06-08 06:43:39 <dave0       > veltas: ah! is it   SP -> data stack   HL -> top of stack    ?
2023-06-08 06:44:01 <veltas      > Yes
2023-06-08 06:44:06 <dave0       > cool
2023-06-08 06:46:57 <dave0       > aha IX is return stack?
2023-06-08 06:48:12 <veltas      > Yes
2023-06-08 06:48:36 <veltas      > IMO it's a good choice for direct threaded and token threaded (of which I can build to both)
2023-06-08 06:49:28 <veltas      > I have been told that it's the 'wrong' choice because Rodriguez did it differently, but I'm pretty sure there are better savings in this choice, like SWAP apparently!
2023-06-08 06:49:59 <veltas      > And I think Rodriguez was trying to build a well, rather than give us water
2023-06-08 06:51:40 <veltas      > Things get very 8-bit when you try subroutine threading, I have no idea what it would even look like, PUSH/POP for data stack access are extremely convenient
2023-06-08 06:52:55 <dave0       > aha IY is the program counter
2023-06-08 06:53:55 <dave0       > z80 has some 16 bit ops
2023-06-08 06:54:20 <veltas      > But not a lot of 16-bit loads, PUSH/POP are the optimum for that
2023-06-08 06:54:41 <veltas      > Which is why I preferred to have that for data stack
2023-06-08 07:09:37 <dave0       > veltas: did you experiment with different NEXT's for direct threaded code?
2023-06-08 07:12:31 <dave0       > wow even the interrupt handlers are written in forth @
2023-06-08 07:12:32 <dave0       > !
2023-06-08 07:14:21 <dave0       > veltas: i think you can use the   EX (SP),HL    trick in EXECUTE
2023-06-08 07:19:01 <dave0       > veltas: can you write an interrupt handler that uses a separate stack?
2023-06-08 07:20:03 <dave0       > i notice that on interrupts you push all the registers onto the stack ... if you use EXX can you set up a separate stack area just for interrupts without ever writing to SP?
2023-06-08 07:21:40 <dave0       > veltas: very nice signed less than
2023-06-08 07:28:34 <veltas      > dave0: I had considered restricting interrupts to special purpose machine code, but I got barked at for suggesting that
2023-06-08 07:29:06 <veltas      > I think Terry(?) or MrMobius said basically you expect to be able to write interrupt handling in Forth, and I don't disagree
2023-06-08 07:30:13 <veltas      > Using separate stacks for interrupts seems like a waste of memory, what's the thought there?
2023-06-08 07:30:20 <dave0       > forth is awesome
2023-06-08 07:31:02 <veltas      > And what different NEXT's would I have? I've got three right now that are different entry points to colon_code
2023-06-08 07:31:23 <dave0       > veltas: if it's possible to use z80's SP as the program counter, next becomes RET
2023-06-08 07:31:52 <dave0       > veltas: but that requires never push'ing anything
2023-06-08 07:32:06 <veltas      > Not possible on Z80 without disabling interrupts
2023-06-08 07:32:15 <veltas      > The interrupt return address goes on SP
2023-06-08 07:32:17 <dave0       > ah okay bugger
2023-06-08 07:32:21 <dave0       > doh
2023-06-08 07:32:39 <dave0       > i thought it might have been in the shadow registers you get with EXX
2023-06-08 07:32:44 <veltas      > The interesting thing to try is probably STC, to see what kind of optimisation is possible there
2023-06-08 07:33:14 <dave0       > subroutine threaded means z80 SP is the return stack
2023-06-08 07:33:20 <veltas      > No EXX is really meant for quick save/restore of registers for interrupts, or alternatively to just have two sets of registers for big calculations
2023-06-08 07:33:40 <veltas      > I use it as the latter so I can do e.g. a 48-bit / 16-bit division in registers
2023-06-08 07:33:58 <dave0       > wow what's the 48 bit divide for?
2023-06-08 07:34:04 <veltas      > M*/
2023-06-08 07:34:21 <dave0       > that's stretching things :-)
2023-06-08 07:34:48 <veltas      > Yeah but the result is still quite good code I think
2023-06-08 07:35:02 <veltas      > Well UM*/ is CODE, and M*/ I think is a colon def
2023-06-08 07:35:47 <dave0       > oh i see it!
2023-06-08 07:36:02 <dave0       > i am reading your     https://raw.githubusercontent.com/Veltas/zenv/master/src/zenv.asm
2023-06-08 07:36:13 <dave0       > i paused on UM* to compare the code :-)
2023-06-08 07:36:41 <veltas      > There's probably improvements possible in there in a number of places
2023-06-08 07:37:21 <dave0       > your code is pretty tight
2023-06-08 07:37:41 <veltas      > The Z80 is really damn fast for an 8-bit CPU when it comes to these kinds of operations
2023-06-08 07:38:12 <dave0       > i find it like a puzzle
2023-06-08 07:38:55 <dave0       > the wild different address modes depending on which registers you use
2023-06-08 07:39:22 <dave0       > HL is like the superman ... it can do anything
2023-06-08 07:40:53 <veltas      > I got UM*/ working properly only in recent months when I sat down and programmed my ZX Spectrum with my linear regression program
2023-06-08 07:40:59 <veltas      > And fixed all the bugs to get it working
2023-06-08 07:41:52 <veltas      > I do like doing fixed-point arithmetic, and it's satisfylingly fast at doing the calculation
2023-06-08 07:42:53 <dave0       > fixed point is bueno
2023-06-08 07:43:05 <veltas      > I originally wrote the program on my desktop computer and now I can write the same program into an 80's 8-bit machine and get the same result, with decent performance
2023-06-08 07:43:25 <dave0       > do you own a real ZX spectrum?
2023-06-08 07:43:37 <veltas      > Yeah I did this programming on my real one
2023-06-08 07:43:43 <dave0       > nice
2023-06-08 07:43:56 <veltas      > This is for me the selling point of Forth, C 'works anywhere' but C isn't an IDE
2023-06-08 07:44:15 <veltas      > Forth works anywhere and it can also be your dev environment
2023-06-08 07:44:19 <dave0       > forth is incredibly interactive
2023-06-08 07:44:36 <dave0       > it being interactive got me in
2023-06-08 07:45:05 <veltas      > For the most part I debug my Z80 Forth words on the actual ZX Spectrum hardware, using my environment
2023-06-08 07:45:29 <veltas      > But the assembly stuff I tend to debug on the emulator because I don't have a step debugger in my Forth
2023-06-08 07:45:52 <veltas      > Although I could actually implement one.....
2023-06-08 07:46:47 <veltas      > I would probably rely on replacing the 3 bytes from next instruction address with "CALL debug_interrupt"
2023-06-08 07:47:36 <veltas      > And then I can dump all regs and drop into the QUIT prompt, and allow resume/step
2023-06-08 07:48:02 <veltas      > I'd be more inclined to try this after writing a disassembler
2023-06-08 07:49:41 <dave0       > do you use the RST instruction?
2023-06-08 07:49:57 <veltas      > Only in BYE, because all the RST locations are in ROM
2023-06-08 07:50:00 <dave0       > instead of writing 3 byte you could write a single byte RST
2023-06-08 07:50:10 <dave0       > oh!
2023-06-08 07:50:44 <veltas      > There is a way of getting one byte... add step debugger to interrupt handler, and make next byte into HALT
2023-06-08 07:51:08 <veltas      > Prevents it working if interrupts are disabled (they are sometimes, rarely, e.g. in BEEP)
2023-06-08 07:51:39 <veltas      > And I don't see advantage of this approach, it makes interrupt handler potentially slower, although now I can 'get' my register state from a known location on the hardware stack
2023-06-08 07:51:59 <veltas      > Which is finickity but reduces code footprint maybe
2023-06-08 07:52:28 <dave0       > forth is so low level :-)
2023-06-08 07:54:58 <veltas      > If I wrote a ROM Forth I would definitely use RST up with common Forth words first
2023-06-08 07:55:19 <veltas      > You would have RST for SWAP/DUP/DROP/EXIT etc
2023-06-08 07:55:37 <veltas      > And then I'd consider it worth being STC
2023-06-08 07:58:21 <veltas      > CALL is 3 bytes and 17 clock cycles, RST is 1 byte and 11 clock cycles, utterly wasted on Sinclair BASIC
2023-06-08 07:59:18 <dave0       > is rom at address 0 ?
2023-06-08 07:59:20 <veltas      > Yes
2023-06-08 07:59:32 <dave0       > oohhh whoops!
2023-06-08 07:59:40 <veltas      > I don't blame them for this short-sightedness, but it's a bit sad
2023-06-08 07:59:59 <veltas      > I don't think most of them are even used that frequently
2023-06-08 08:00:05 <dave0       > the computers i've used all had rom at the top of memory
2023-06-08 08:00:27 <dave0       > wait
2023-06-08 08:00:34 <dave0       > high memory not necessarily the top
2023-06-08 08:00:41 <dave0       > but address 0 was always ram
2023-06-08 08:01:12 <veltas      > It would have made perfect sense here to have ROM at C000, and RAM start at 0000, with shared video memory starting at 4000
2023-06-08 08:01:17 <veltas      > Alas
2023-06-08 08:01:31 <veltas      > Z80 starts at address 0000 to be fair
2023-06-08 08:02:27 <dave0       > veltas: i watched youtube videos on speed running manic miner and jet set willy for zx spectrum :-)
2023-06-08 08:02:38 <dave0       > so influential
2023-06-08 08:33:43 <MrMobius    > I definitely would not be the one advocating interrupts written in forth :)
2023-06-08 09:15:32 <KipIngram   > Wow - missed a nice conversation.
2023-06-08 09:16:06 <KipIngram   > I wouldn't lean that way either (handlers in Forth), but for it to be POSSIBLE is kind of nice.
2023-06-08 09:16:18 <KipIngram   > Might be useful for initial tinkering with something.
2023-06-08 09:29:00 <KipIngram   > What I would likely do is have a generic machine code handler that did some quick touch to some data structures that my Forth code would see and respond to.  But I'm a believer in keeping interrupt handlers as absolutely minimal as possible.  I have them "steer other things."
2023-06-08 09:30:25 <KipIngram   > Regarding "quick save and restore of registers," I lament the fact that somewhere along the way the x86 evolution lost its "pusha / popa" feature.
2023-06-08 09:30:35 <KipIngram   > That just seems like an obvious instruction to want to me.
2023-06-08 09:30:45 <KipIngram   > I guess they just ran out of encoding room.
2023-06-08 09:39:46 <KipIngram   > As far as the "possibility" of Forth interrupt handlers goes, I feel like what we're trying to create in these situations is a virtual machine, that RUNS FORTH.  So you'd like to think you could do anything at that level if you chose to.
2023-06-08 09:50:46 <KipIngram   > How likely do you guys think it is that I'll wind up needing more than 64k xt's in a system?
2023-06-08 09:51:04 <KipIngram   > I'm still trying to just "make this decision" about two-byte vs. four-byte xts.
2023-06-08 09:52:11 <KipIngram   > Four-byte has the (small) advantage of lodsd clearing the high bits of rax, whereas lodsw does not.  So if I go two bytes, I have to make sure that I keep rax high bits clean.
2023-06-08 09:52:33 <KipIngram   > That's not terribly hard to do, but it is "something to do."
2023-06-08 09:53:16 <KipIngram   > Four bytes really means an "infinite" supply of xts, but pretty much doubles the size of every definition.
2023-06-08 10:03:28 <KipIngram   > Side note - any word defined with a builds> does> defining word will consume two xts.
2023-06-08 10:17:27 <KipIngram   > As far as speed goes, lodsd vs. lodsw seems to make pretty much zero difference.  Lost in the noise.
2023-06-08 10:49:59 <KipIngram   > I think I'm not going to jmp <reg> for next.  My next code is just four bytes long, and now that I'm timer-ticking in docol instead of next that never ever gets changed in any way.  I'm just going to tack those four bytes onto each primitive.
2023-06-08 10:50:55 <KipIngram   > jmp <reg> is two bytes, so that's only two bytes extra per.
2023-06-08 11:05:02 <KipIngram   > You know, maybe I should set aside my "not touching" rsp.  If I used rsp as my return stack then docol would just be push rsi; mov rsi [reg+8*rax]
2023-06-08 11:31:15 <KipIngram   > So, for those of you with systems that support multithreading, how to you deploy "variables in the dictionary" vs. "user" variables?  It feels to me like in most cases a created thread probably really shouldn't be making any changes "in the dictionary."
2023-06-08 11:31:46 <KipIngram   > I mean, unless the purpose of that thread is system related in some way.
2023-06-08 11:32:02 <KipIngram   > A thread just doing some generic calculation seems like it ought to be working with private data.
2023-06-08 11:38:53 <veltas      > Yes but apparently you do live rent free in my head anyway MrMobius ;)
2023-06-08 11:40:09 <veltas      > KipIngram: PolyForth has a special wordset for USER variables, I think threads then get their own dictionaries (???) when they're running
2023-06-08 11:40:11 <M-Sci       > Exactly!  Destructive Update needs to be clarified.  IMHO, all Destructive Update can be _reduced_ to a single _Implicit_ Parameter!  MMIO?!
2023-06-08 12:18:58 <KipIngram   > The way I kind of see it is that when writing the code that will eventually lead to a thread, I'll declare user variables, and the totality of those declarations will eventually tell me how much user var space to allocate in the task's memory block.
2023-06-08 12:19:10 <KipIngram   > And execution of those variables will just return addresses in that region.
2023-06-08 12:19:31 <KipIngram   > I.e., it will vary - there won't be a "fixed list" of user variables.
2023-06-08 12:19:54 <KipIngram   > Though there will be some that are always required, as a "starting point."  SP0 and RP0, for example.
2023-06-08 12:21:08 <KipIngram   > I'll have a register assigned to holding the task block address for the currently running task - user vars will just offset from that.
2023-06-08 12:21:31 <KipIngram   > And of course the remainder of that region will be shared by the stacks.
2023-06-08 14:25:48 <M-Sci       > veltas, KipIngram: Could Boolean Operations be generalized to operations on Subroutines resulting in multitasking?!
2023-06-08 14:26:04 <M-Sci       > Is that Unification?
2023-06-08 14:26:18 <KipIngram   > Oh gosh, I'm the wrong person to ask about something like that.
2023-06-08 14:26:40 <KipIngram   > Sounds a little "formal CS" for my sandbox.
2023-06-08 14:26:58 <KipIngram   > Can you give a small example of what you mean?
2023-06-08 14:27:30 <KipIngram   > Maybe if I can connect it up with what a processor might actually be doing I'll have something worthwhile to say.
2023-06-08 14:27:54 <KipIngram   > Boolean operations -  you just mean the usual AND, OR, etc.?
2023-06-08 14:28:31 <KipIngram   > Oh, maybe I see what you mean - the AND of two subroutines would be gotten by running them concurrently and ANDing their result?
2023-06-08 14:29:04 <KipIngram   > That makes me think of what I regard as "fine grain parallelism."
2023-06-08 14:29:23 <KipIngram   > That's the kind of parallelism that everyone was hot for back when I was in school and deeply interested in parallel computing.
2023-06-08 14:29:55 <M-Sci       > Yes, examples are great idea!  ' ( and subr1 subr2 ) should, AFAICU, be 2 threads.
2023-06-08 14:29:56 <KipIngram   > Things have gone a somewhat different direction, though - modern processors are more well-suited for what they call "flow-based programming."
2023-06-08 14:30:35 <thrig       > electricity flow is generally beneficial
2023-06-08 14:31:02 <KipIngram   > Where the independent threads are working pretty separately from one another, on totally different "phases" of what needs to be done to your data, and they're arranged as a pipeline the data flows through.  One thread does phase one work, then hands the results completely off to another thread that does phase 2.  Meanwhile, that first thread is doing phase 1 work on the next batch of data.
2023-06-08 14:31:22 <KipIngram   > This way they tend not to step on each other's toes the same way, since they're working with completely separate data sets.
2023-06-08 14:31:24 <M-Sci       > thrig: :) wut?
2023-06-08 14:31:32 <KipIngram   > They don't constantly invalidate one another's cache lines, and so on.
2023-06-08 14:31:57 <KipIngram   > So you've got parallelism, but it's at a lot higher level.
2023-06-08 14:32:54 <KipIngram   > The fine grain stuff is very appealing intellectually, but it's hard to implement effectively.
2023-06-08 14:33:14 <KipIngram   > Well, hard to implement EFFICIENTLY.
2023-06-08 14:39:13 <KipIngram   > So, I thought of a slightly different "twist" on that "ring buffer scratch space" thing we've been talking about.
2023-06-08 14:40:29 <KipIngram   > Instead of a ring that data items are directly stored in, it would use one additional level of indirection, and the actual item storage would be managed by an allocator.   The ring would be a ring of "handles," so to speak.  When a new object needed to be transiently stored, it would take the next element of the ring.  Let's assume it's empty - that we've just started.
2023-06-08 14:40:57 <KipIngram   > A block of RAM would be allocated for that item, and the ring element would point to it.  Then the address of that ring element would be what landed on the stack.
2023-06-08 14:42:08 <KipIngram   > You'd do anything you wanted with that.  Eventually, when  you go to use a new ring element, it will be occupied.  So you either re-use the allocated RAM for already connected with it, or you free that block and allocate a new one (maybe you want a different size this time).
2023-06-08 14:42:28 <KipIngram   > At any time you could "close" your scratch space, and it would just run through the ring and deallocate everything.
2023-06-08 14:58:16 <KipIngram   > The gain this extra layer brings you is that you could allocate as much RAM as an object needed - you could work with huge arrays, for example, and it wouldn't fill up your whole ring buffer.
2023-06-08 14:59:53 <KipIngram   > If I wanted to be able to detect that I'd just tried to use a handle that had been overwritten, that wouldn't be too hard to work in.
2023-06-08 15:01:01 <KipIngram   > And, if you wanted to keep something long term, you could "de-ring it."  Then you'd be responsible for freeing it eventually, but it would be as though you'd manually allocated it yourself.
2023-06-08 15:05:07 <KipIngram   > The whole thing got me thinking about literal data again.  The main reason Forth doesn't have traditional string support is because it doesn't have a natural place to put strings.   This gives one.  And if you think about, just as 123 and 0x42 are literals, "kitten" is too.
2023-06-08 15:05:47 <KipIngram   > There's really nothing *inherently* wrong with Forth recognizing such a thing as a literal string.  It's no different from recognizing that 0x is indicating a hexadecimal number string.
2023-06-08 15:06:10 <KipIngram   > It's not as though one of those things is "ok" and the other one is "wicked."
2023-06-08 15:06:43 <KipIngram   > For that mater, knowing that 123 should be interpreted as a decimal number is ALREADY that same kind of built-in knowledge.
2023-06-08 15:07:02 <KipIngram   > It's already a deviation from "look space delimited strings up in the dictionary."
2023-06-08 15:07:58 <KipIngram   > And just as we could define : 123  246 ; if we wanted to, we could write : "kitten"  "puppy" ; if we wanted to.
2023-06-08 15:08:20 <KipIngram   > Neither would be very sensible, but Forth would happily cooperate.
2023-06-08 15:10:21 <KipIngram   > So what I'm thinking is try the dictionary first like always, and if that's a fail then anything that's started and ended with matching sets of quote marks (so, "abc" or 'abc' or ''a"b'c'' or whatever) is a literal string and passes.
2023-06-08 15:10:23 <unjust      > i think it's the parsing logic required for that sort of string representation which gets frowned upon
2023-06-08 15:10:47 <KipIngram   > Well, NUMBER isn't exactly a terse little word either.
2023-06-08 15:11:01 <KipIngram   > Especially if you want to support doubles or floats, multiple bases, etc.
2023-06-08 15:11:08 <KipIngram   > Yes, parsing can get involved.
2023-06-08 15:11:39 <KipIngram   > But friendly handling of string literals is a pretty big thing to just give up with a shrug.
2023-06-08 15:12:46 <KipIngram   > And then you have lists, dictionaries, and so on - things that are just BASIC to modern proramming, that Forth just offers no graceful way to work with.
2023-06-08 15:13:03 <KipIngram   > And, a related topic.
2023-06-08 15:13:05 <unjust      > escaping double quotes, and the fact that the double quotes aren't separated by whitespace from the character array definitely adds a ton of complexity - imho, it's worth it. at least if your system is geared toward text processing and interoperability with modules written in languages which don't natively support counted strings.
2023-06-08 15:13:28 <KipIngram   > We can extend Forth's ability to "do things" (it's code base) all over creation.  Why can't we extend it's ability to interpret input?
2023-06-08 15:14:04 <KipIngram   > What if your application just begs for support for an "industry accepted" way of formatting input data?
2023-06-08 15:14:34 <KipIngram   > The directive historically has been "Nope - find a way to shoehorn that into what Forth will accept."
2023-06-08 15:15:14 <unjust      > as in treating input data as if it were code?
2023-06-08 15:17:36 <KipIngram   > More just a way to say to Forth "here is what my input is going to look like, and here is how that should be interpreted."
2023-06-08 15:18:09 <KipIngram   > I.e., you describe the format of the input somehow, and provide code as necessary to turn that into an in-RAM data structure that meets your needs.
2023-06-08 15:18:24 <KipIngram   > We have no problem on the code side of that - that's good already.
2023-06-08 15:19:39 <KipIngram   > And yes - I am talking here about adding things that are more common in language handlers for other languages.
2023-06-08 15:20:20 <KipIngram   > But it's really fairly limiting to be confined in the straightjacket we're in.  It doesn't stop us from getting the job done, but it makes it more cumbersome and probably is part of what puts new people off of the language.
2023-06-08 15:20:49 <KipIngram   > I LOVE Forth and have for decades, but even I wince a little at the idea of doing certain string heavy things in Forth that I wouldn't bat an eye about implementing in Python.
2023-06-08 15:22:20 <KipIngram   > This is more stuff that perhaps wouldn't need to be in Forth outof the box, but might get added by loading some code when you needed these things.
2023-06-08 15:22:45 <KipIngram   > Although the string handling I kind of thing should be there.  But the other stuff I mentioned - lists, dictionaries and so on - maybe it's not ALL "ground floor."
2023-06-08 15:26:16 <unjust      > i'm using an irc client written in my own 'forth', which is fairly string-centric in terms of parsing this very protocol. but then i'm riding ontop of javascript and take full advantage of wrapper words that inevitably call javascript string (, array and object) methods.
2023-06-08 15:26:51 <KipIngram   > Right.  I'm... not.  I'm living as close to the metal as I can.
2023-06-08 15:27:43 <KipIngram   > I don't even really want to just "use" the OS mmap as my "routine" allocator - I want to allocate a big block of RAM once at startup and then do my own allocation out of that.
2023-06-08 15:28:04 <KipIngram   > That one call to mmap is a concession to the fact that yes, I am cohabitating with an os.
2023-06-08 15:28:37 <KipIngram   > Maybe I'll concede a bit more and make several calls to mmap at startup, for my various regions.
2023-06-08 15:28:49 <KipIngram   > But I'm not sure about that yet.
2023-06-08 15:30:08 <KipIngram   > Your way of working still doesn't address the input format side of the equation.  You can hand it off to javascript after you've got it, but you still have to "get it" Forth's way.
2023-06-08 15:30:33 <KipIngram   > If I understand right - maybe some of these javascript bits can actually input stuff for you.
2023-06-08 15:33:06 <unjust      > i only point it out, as it's easy to prototype with concepts when you're stuck in a high-level language already. of course not everything will be useful from the perspective of implementing the same ideas on bare metal.
2023-06-08 15:34:03 <unjust      > not sure if you can make sense of it, but PARSE-LINE in https://github.com/jhswartz/eczema-irc/blob/master/parse.js deals with parsing each line received from an irc server
2023-06-08 15:34:59 <KipIngram   > I don't know what, if any, answer I'm proposing here.  I'm just having an episode of the "gnawing idea" that things could be improved.
2023-06-08 15:35:36 <KipIngram   > I don't want to just gut the very nature of Forth, and it may be that I can't find any good middle ground (I'm pretty sure I can for strings, but beyond that... I don't know).
2023-06-08 15:36:17 <KipIngram   > One of the things I want to be able to do someday is numerical programming, like one does in Octave or Matlab.  That calls for a friendly way to give the thing vectors, matrices, and so on.
2023-06-08 15:36:33 <unjust      > would you want to declare your input format in something BNF-like and expect a suitable parser to be generated?
2023-06-08 15:36:39 <KipIngram   > I just really don't love having to separate my ['s and ]'s from everything with spaces - it's ugly.
2023-06-08 15:37:37 <KipIngram   > I don't know the answer to that yet.  I don't love that idea, but I might find there's no better way to do it.
2023-06-08 15:38:13 <KipIngram   > One thing I thought of at one point was for Forth to have a list of regular expressions it matched the input with.  If one of them passed, great - it would know then what to do with the thing.  If none of them did, error.
2023-06-08 15:38:20 <KipIngram   > And that would be a user-modifiable list.
2023-06-08 15:39:57 <KipIngram   > I haven't been sitting around all day thinking about this - these thoughts are "episodic" and just popped up when I first spoke up about it a few minutes ago.
2023-06-08 15:40:16 <KipIngram   > I want strings, for sure.  Beyond that, I'll have to ponder.
2023-06-08 15:40:57 <KipIngram   > Let's say I type "this is a string."
2023-06-08 15:41:03 <KipIngram   > So Forth gets "this
2023-06-08 15:41:10 <KipIngram   > It looks that up in the dictionary and doesn't find it.
2023-06-08 15:41:17 <KipIngram   > We pass it to NUMBER, and that fails.
2023-06-08 15:41:49 <KipIngram   > I see no reason at all why I couldn't see that it started with " and have that trigger looking on ahead in the input to see if there's a closing " out there somewhere, and if there is grab all of that as a string.
2023-06-08 15:42:23 <KipIngram   > So that, at least, can be done without just crucifying Forth's "space delimited words" paradigm.
2023-06-08 15:42:37 <KipIngram   > An this ring buffer thing gives me a place to put that string.
2023-06-08 15:43:24 <KipIngram   > Multi-line strings - no problem in a source block.  it's really one long input string anyway.
2023-06-08 15:43:34 <KipIngram   > At the terminal... well, that's a little problematic.
2023-06-08 15:43:50 <KipIngram   > Because you wouldn't SEE the closing quote yet, so how do you know whether one is planned or whether it's an error?
2023-06-08 15:46:52 <unjust      > continue reading input assuming everything is a part of the string until a token that is terminated by a double quote (which is not escaped) is identified? or until some suitable interrupt is generated (ctrl+c/SIGINT or similar?) which would cancel input processing
2023-06-08 15:47:10 <KipIngram   > Sure, that would be the only way to proceed if you wanted that support.
2023-06-08 15:47:26 <KipIngram   > I can already spread definitions across multiple console lines if I want to.
2023-06-08 15:47:46 <KipIngram   > If I hit Enter with a definition open, I get a green ... prompt instead of a green ok prompt.
2023-06-08 15:47:57 <KipIngram   > Then eventually I type a ; and it's happy.
2023-06-08 15:48:08 <KipIngram   > Same thing would work in this scenario too.
2023-06-08 15:50:13 <KipIngram   > For multi-line defs, Forth works in a way that just takes that totally in stride.
2023-06-08 15:51:12 <KipIngram   > To do that with strings, though, points toward a more complex STATE.
2023-06-08 15:51:38 <KipIngram   > execute/compile, open literal vs. not, etc.
2023-06-08 15:52:27 <KipIngram   > Honoring \n would give you another way of entering multi-line literals.
2023-06-08 15:52:53 <KipIngram   > But  now Forth has to do more than just "grab the string"; it has to process it too.
2023-06-08 15:53:12 <KipIngram   > Of course, it processes number digits, so that's not actually "new."
2023-06-08 15:53:48 <KipIngram   > Anyway, my point is that a long time ago someone just made a more or less arbitrary call about what amount of "input interpretation" would be in Forth.
2023-06-08 15:53:55 <KipIngram   > It's not necessarily the only way it can be.
2023-06-08 15:54:10 <KipIngram   > We are already special casing certain types of input.
2023-06-08 15:54:34 <KipIngram   > We don't think about it, because "that's just how it's always been done."
2023-06-08 16:01:05 <KipIngram   > In fact, that's really why I brought the subject up to start with earlier - just to point out that we already do this kind of thing, in ways that have been declared "acceptable" by the powers that be.
2023-06-08 16:17:33 <KipIngram   > What got it on my mind was thinking about that ring thing; that's a nice place to put strings.
2023-06-08 16:17:43 <KipIngram   > Got 'em on my  mind, and I just went from there.
2023-06-08 16:27:01 <unjust      > what's the ring thing?
2023-06-08 16:28:21 <thrig       > From Sauron with Love
2023-06-08 16:30:47 <KipIngram   > Oh, we've talked off and on (or I have, at least - crc seems to have some things along these lines in his stuff too) about temporary storage of things (stuff that doesn't fit in a cell) in a "ring buffer" - you just grab the next chunk of the ring and use it - return the address on the stack.  The idea is that by the time the ring wraps back around, you're done with that item.
2023-06-08 16:31:05 <KipIngram   > A way of "dynamically allocating" memory without having to actually keep up with it, free it, and so on.
2023-06-08 16:31:09 <thrig       > (hopefully)
2023-06-08 16:31:14 <KipIngram   > Hopefully.
2023-06-08 16:31:36 <KipIngram   > Obviously problems could ensue if you held on to an address for a few hours or days and then tried to use it.
2023-06-08 16:32:03 <KipIngram   > I proposed a slightly more complicated version of the stame thing earlier, that got the same basic behavior but a little more robustly.
2023-06-08 16:32:16 <KipIngram   > And which would let you "decouple" items from the ring without having to copy them.
2023-06-08 16:32:23 <unjust      > is it one giant system-wide ring? or do you allocate them on some group/module/word basis?
2023-06-08 16:32:46 <KipIngram   > Ring of pointers, pointing to allocated blocks.  The ring code would take care of deallocating those, unless you popped one out of the ring.
2023-06-08 16:33:14 <KipIngram   > Initially it was one.
2023-06-08 16:33:31 <KipIngram   > But in this latest thinking I'm envisioning that you can "open" a ring whenever you want to.
2023-06-08 16:33:42 <KipIngram   > And if you then close that ring everything in it gets deallocated.
2023-06-08 16:33:56 <KipIngram   > So different code could open different rings.
2023-06-08 16:34:13 <KipIngram   > I haven't thought that through very far yet, though.
2023-06-08 16:34:28 <KipIngram   > Might be an issue with certain bits of functionality knowing which ring to use.
2023-06-08 16:43:47 <KipIngram   > Maybe it's a ring per thread.
2023-06-08 16:44:00 <KipIngram   > So the ring address goes in a user variable.
2023-06-08 16:44:08 <KipIngram   > Possibility at least.
2023-06-08 16:44:31 <KipIngram   > Maybe you don't open and close it - it's just  "there" and if you use it it gets setup.
2023-06-08 16:46:00 <KipIngram   > I ought to go back and read that stuff we had here a few months back about the "belt processor."  Maybe some of those thoughts fit here somewhere.
2023-06-08 16:48:41 <KipIngram   > https://millcomputing.com/blog/wp-content/uploads/2013/12/2013-07-11_mill_cpu_belt.pptx
2023-06-08 17:07:55 <WilhelmVonWeiner> did pointfree used to be a member of this channel?
2023-06-08 17:11:27 <unjust      > WilhelmVonWeiner: i remember seeing that nick in the freenode incarnation of this channel
2023-06-08 17:12:46 <WilhelmVonWeiner> yeahh i just noticed on his reddit that he posted about gangstalking 2 years ago
2023-06-08 17:12:51 <WilhelmVonWeiner> and disappeared
2023-06-08 17:12:52 <WilhelmVonWeiner> weird
2023-06-08 17:15:12 <unjust      > i thought mentioning his presentation about the case for FIFOs in forth (a few weeks back) might have resurrected him but it didn't
2023-06-08 17:16:19 <WilhelmVonWeiner> @lowfatcomputing on twitter so he seems alright
2023-06-08 19:09:49 <KipIngram   > You know, this belt processor would probably be completely unprogrammable without software assistance.
2023-06-08 19:10:00 <KipIngram   > I'd hate to have to program that thing by hand.
2023-06-08 19:11:21 <KipIngram   > From what I can glean, all the operation units are fixed timing, so you know exactly when each result is going to be dropped on the belt.  So you know which slot it's in at each cycle, and the next guy that needs it has to scoop it up from a known expected location at the right time.
2023-06-08 19:11:37 <KipIngram   > And this is for a crap load of operation units, all working at the same time.
2023-06-08 19:12:21 <KipIngram   > I suppose you could  probably program it "very inefficiently" in a more easy to keep your head around sort of way, but to really squeeze the juice out of it... lots to keep up with.
2023-06-08 19:12:53 <KipIngram   > Wasn't it these guys that hijacked the gcc toolchain for their chip design process?
2023-06-08 19:15:37 <Zarutian_iPad> you mean using C as their macro assembler?
2023-06-08 19:16:08 <KipIngram   > Yeah - along those lines.
2023-06-08 19:16:35 <Zarutian_iPad> that is, writing the assembly in C which compiles to an executable that then spits out the assembled binary executable?
2023-06-08 19:16:42 <KipIngram   > They had a whole video about just that.
2023-06-08 19:17:11 <KipIngram   > And then I guess they added something else at the end to convert the output of that into actual chip mask format.
2023-06-08 19:17:17 <Zarutian_iPad> a trick I have used myself but using js instead of C
2023-06-08 19:17:50 <KipIngram   > I've used Python to create assembly to make a Forth.
2023-06-08 19:18:04 <Zarutian_iPad> oh! yeah they make the Register to Register and even netlist formats of their chips that way
2023-06-08 19:19:03 <Zarutian_iPad> said RTL or netlist is then fed into ASIC or FPGA layout software plus some subassemblies libraries
2023-06-08 19:20:08 <KipIngram   > My sister sent me a link yesterday - she found photos of my dad back in the early 1960's.  Photo archive for the little university he taught at at the time.
2023-06-08 19:20:11 <KipIngram   > I like this one:
2023-06-08 19:20:13 <KipIngram   > https://digitalcommons.jsu.edu/lib-ac-histimg/31933/
2023-06-08 19:20:45 <KipIngram   > He passed away in 1999.
2023-06-08 19:21:09 <KipIngram   > My mom's truckin' right along.
2023-06-08 19:21:30 <KipIngram   > She'll be 89 in September.