2023-08-22 00:00:23 <KipIngram   > Yeah.  It's all nice and clean.  The doc I was reading was on using group theory to organize particle physics.
2023-08-22 00:00:33 <thrig       > you don't pull, you use a sword
2023-08-22 00:00:38 <KipIngram   > :_)
2023-08-22 00:00:39 <KipIngram   > :-)
2023-08-22 00:01:34 <KipIngram   > I've known tensor stuff for a long time, and this all turns out to be very similar ideas.  I just couldn't "tell that" in the earlier exposures because too much of the language was unknown to me.
2023-08-22 00:03:47 <xelxebar    > I find a similar dynamic with a lot of IT stuff, too. There's tons of historical context that's relevant for understanding the motivation behind current designs—CPU, OS, coreutils userspace, Kubernetes—but it's all a big blob of ad-hociness when viewed from a "purely technical" lens.
2023-08-22 00:04:13 <xelxebar    > KipIngram: Have I mentioned Metamath to you before? Think you'd really get a kick out of it.
2023-08-22 00:04:26 <KipIngram   > I kind of hate to admit that I took tensor calculus in grad school, and even though I got good enough turning the crank to make an A I didn't really "see" the big picture.
2023-08-22 00:05:06 <KipIngram   > But then a few years ago I was watching a set of YouTube lectures on general relativity by Leonard Susskind.  He always lays out necessary math at the beginning of his courses.  And all the pieces just kind of fell into place.
2023-08-22 00:05:27 <xelxebar    > ^ I had the same issue with linear algebra in undergrad. Took *waaaay* too long to realize what a matrix means geometrically and whey they're interesting.
2023-08-22 00:05:51 <KipIngram   > Linear algebrra is so so critical to so many things.
2023-08-22 00:06:13 <KipIngram   > I took that in graduate school too, and that one I got to start with.
2023-08-22 00:06:13 <KipIngram   > Prof was really good.
2023-08-22 00:06:38 <xelxebar    > Right?! It's like THE subject. I feel like most of physics is leveraging tricks to reduce problems into linear algebra.
2023-08-22 00:06:49 <KipIngram   > It is.
2023-08-22 00:07:06 <KipIngram   > Though stuff having to do with "differentials" is really important too.
2023-08-22 00:07:15 <KipIngram   > Calculus type concepts.
2023-08-22 00:07:45 <thrig       > obviously derivative work
2023-08-22 00:09:02 <xelxebar    > Well, differentiation is a *linear* operator, so you can actually think of it as a kind of "infinite dimensional matrix"
2023-08-22 00:10:14 <xelxebar    > It's really just a small subset of linear algebra over infinite-dimensional vectior spaces (i.e. the vectors are just functions).
2023-08-22 00:10:24 <KipIngram   > That's true.
2023-08-22 00:12:27 <xelxebar    > I remember the epiphany feeling when seeing functions as a vector. Vectors are just "finite lists of numbers", so they can be implemented as functions from some finite set to the reals/complex/whatever field of interest.
2023-08-22 00:13:21 <KipIngram   > Yeah - that's a neat thing.  I had a nice moment like that not too long ago, when I realized how normal calculus interals were an example of the generalized Stoke's Law.
2023-08-22 00:14:02 <KipIngram   > I.e., that the two end-points of your integration interval are the "boundary" of the contained "volume" between them.
2023-08-22 00:14:39 <xelxebar    > Oh... That's a super deep theorem!! Still don't fully grok the complete general rendition, though. Connects with lots of very interesting abstract algebra and group theory.
2023-08-22 00:15:16 <KipIngram   > Yeah, that's where I've been hammering around.
2023-08-22 00:15:36 <KipIngram   > I won't say I've mastered it, but I'm starting to get the brorad outlines.
2023-08-22 00:16:05 <xelxebar    > Cool. You have fun hobbies :)
2023-08-22 00:19:26 <KipIngram   > I just like understanding how things work.
2023-08-22 00:26:25 <xelxebar    > Same. Used to terrorize parents as a kid by disassembling everything I could.
2023-08-22 00:30:15 <KipIngram   > Heh.  My wife did that to her mom's bicycle when she was a kid.
2023-08-22 01:01:27 <xelxebar    > Now I've moved on to disassembling x86-64 elf binaries :P
2023-08-22 01:06:14 <iyzsong     > xelxebar: i don't know, it seems lacking, i think 'ls/cd/cat/less' (or DOS ones) could be added to DuskOS.
2023-08-22 01:07:21 <iyzsong     > i'm stupid to not learn a little math in unversity, waste too much time with gaming..
2023-08-22 01:26:53 <xelxebar    > Okay, noob time. Given an address of a (length-prefix) string, how does one generally print it out?
2023-08-22 01:27:08 <xelxebar    > iyzsong: You're probably more fun to be around, though :P
2023-08-22 01:29:20 <xelxebar    > I wasted tons of time in university, too, though. Agonized over so many philosophically vacuous questions.
2023-08-22 02:03:32 <xelxebar    > Found it! f" /doc/usage.txt" page console :self file :spit
2023-08-22 02:08:30 <xelxebar    > Had to put together doc/sys/file.txt and doc/text/pager.txt
2023-08-22 04:32:45 <veltas      > xelxebar: TYPE
2023-08-22 04:33:01 <veltas      > PAGE clears the screen (or goes to next page if printing physically)
2023-08-22 04:33:16 <veltas      > And CR goes to next line
2023-08-22 04:52:55 <xelxebar    > veltas: Oh, duh... I even read the implementation of TYPE.
2023-08-22 04:53:40 <xelxebar    > Hrm. `page' on DuskOS seems to do something different. SmithForth doesn't even implement it.
2023-08-22 04:53:49 <xelxebar    > Will just have to dig in, I guess!
2023-08-22 05:01:58 <veltas      > SmithForth can't really implement it portably, although it's not too much of an assumption to use ANSI escape codes
2023-08-22 05:02:40 <veltas      > Although that won't work on a printer, or sending to a file, for example.
2023-08-22 06:39:46 <KipIngram   > xelxebar: Traditionally TYPE gets implemented using EMIT (loops over it) - the idea is that KEY and EMIT be the only things that have to be 'targeted" to your platform.
2023-08-22 06:40:09 <KipIngram   > I did it the other way around, though - I wrote EMIT using TYPE.
2023-08-22 06:40:19 <KipIngram   > For performance.
2023-08-22 06:40:32 <KipIngram   > EMIT is TYPEing a one-char string.
2023-08-22 06:41:41 <veltas      > "Traditionally TYPE gets implemented using EMIT" ... I don't know about tradition but typically TYPE is the 'real' word and EMIT uses TYPE now
2023-08-22 06:41:51 <veltas      > For performance, like you did
2023-08-22 06:42:06 <veltas      > And TYPE is also usually vectorised, or TYPE' is, etc.
2023-08-22 06:42:15 <veltas      > So you can redirect output
2023-08-22 06:44:14 <KipIngram   > It makes good sense.  I always used old material for my references, though.
2023-08-22 06:44:14 <xelxebar    > Interesting. SmithForth adds one more datapoint to EMIT calling TYPE.
2023-08-22 06:46:48 <xelxebar    > veltas: Good point about portability and PAGE. SmithForth isn't dynamically linked, so it couldn't easily use curses to access the terminfo db.
2023-08-22 06:47:27 <xelxebar    > KipIngram: How do you gave PAGE implemented? ANSI escapes like veltas mentioned?
2023-08-22 06:50:02 <veltas      > I think he uses terminfo or termcap and escapes. In my design you can do ESCAPES ON to get prettier output in the terminal
2023-08-22 06:50:47 <veltas      > I'd rather just ask the user whether they want escapes than add the highly unportable code needed to find out
2023-08-22 06:51:33 <veltas      > And if you don't have ANSI escapes support... no dice!! You still get ASCII + ANSI control characters
2023-08-22 06:52:05 <veltas      > Well UTF-8 because I don't intercept 127 >
2023-08-22 06:54:52 <veltas      > So I might do  : PAGE   ESCAPES @ IF 27 EMIT ." [H" 27 EMIT ." [2J" ELSE CR CR THEN ;
2023-08-22 06:54:55 <veltas      > or similar
2023-08-22 06:57:17 <veltas      > I'd probably have    : ES   27 EMIT ;   or similar as well
2023-08-22 06:59:01 <veltas      > Or ESC maybe
2023-08-22 06:59:10 <xelxebar    > veltas: Oh cool. Didin't realize you had a Forth! Is it in a public repo somewhere?
2023-08-22 07:00:11 <veltas      > It's in progress but will slowly appear here: https://github.com/veltas/forth
2023-08-22 07:00:39 <veltas      > I haven't written my block serialisation yet, when I do I can add more to the repo
2023-08-22 07:01:03 <veltas      > So there's not really anything to see yet
2023-08-22 07:01:04 <xelxebar    > 27 is decimal, right? Didn't realize ETB was interpreted as escape in ansi.
2023-08-22 07:01:46 <veltas      > That's 23 in ASCII
2023-08-22 07:01:52 <veltas      > 27 is ESC (escape)
2023-08-22 07:01:55 <KipIngram   > Yes, 27 is escape.
2023-08-22 07:02:21 <xelxebar    > Oh, I was reading the octal column. Duh.
2023-08-22 07:02:38 <xelxebar    > 1B hex. Got it.
2023-08-22 07:03:52 <veltas      > I do use hexadecimal sometimes but usually my source is decimal by default
2023-08-22 07:04:05 <veltas      > I don't use the base prefixes because they're a bit newer
2023-08-22 07:04:50 <xelxebar    > I don't have the control block memorized yet, unfortunately.
2023-08-22 07:05:29 <xelxebar    > veltas: Just see to-blocks.4th in here. You slowly copying code over?
2023-08-22 07:07:13 <veltas      > I was just saying I've not written block serialisation yet
2023-08-22 07:07:36 <veltas      > I'm developing it in blocks so the only thing that's visible right now is the serialised block loader
2023-08-22 07:08:03 <veltas      > The idea is I'll end up with files in there containing the serialised contents of blocks
2023-08-22 07:08:23 <veltas      > And you can load it all up into blocks using any forth with file support
2023-08-22 07:08:46 <veltas      > It's a cross forth but I want to be able to bootstrap compilation from any normal ANS Forth
2023-08-22 07:09:29 <xelxebar    > Oh. That's cool.
2023-08-22 07:13:34 <veltas      > xelxebar: There's some more code https://termbin.com/weta
2023-08-22 07:14:15 <veltas      > That's the editor I'm developing it with
2023-08-22 07:14:24 <veltas      > And the package support library
2023-08-22 07:51:34 <KipIngram   > In the F18A, the last three bits of an 18-bit word can be used as a fourth instruction slot, but only for the eight instructions that "fit" (i.e., the remaining two bits of the instruction are zero, so the processor can "complete" the 5-bit instruction.  Those instructions are 1) return, 2) literal fetch (fetch using instruction pointer with post-increment), 3) store using instruction pointer with
2023-08-22 07:51:35 <KipIngram   > post-increment, 4) unext (loop within cell), 5) +* 6) + 7) dup, and 8) nop.
2023-08-22 07:51:39 <KipIngram   > I see the reasoning in most of those.
2023-08-22 07:52:20 <KipIngram   > In my 32-bit setup, I will only have two "final slot" bits, so i only get four such instructions, and I have to use one of them as a trigger to load the next instruction cell.  So I really just get three.
2023-08-22 07:52:52 <KipIngram   > So that's a choice I have to make.  I'm leaning toward 1) return, 2) literal fetch, and 3) unext.
2023-08-22 07:53:06 <veltas      > What does that mean "trigger to load the next instruction cell"?
2023-08-22 07:53:26 <veltas      > That just sounds like an instruction fetch, which I'm assuming is automatic
2023-08-22 07:53:50 <KipIngram   > Basically, my "NEXT" operation will be to strip off the next six bits of the current instruction word and shift it down six bits.
2023-08-22 07:54:09 <KipIngram   > I don't want to have to include extra code to count how many times I've done that and decide when to fetch the next cell.
2023-08-22 07:54:18 <KipIngram   > So I'm going to use instruction 0b000000 to do that.
2023-08-22 07:54:31 <KipIngram   > Eventually you'll get all zeros just from shifting out everything in the word.
2023-08-22 07:55:16 <veltas      > I still don't understand
2023-08-22 07:55:18 <KipIngram   > Yes, I could keep up with how many bits I've shifted out and "know" when to load the next cell, but the code to do that would introduce inefficiency in the main NEXT "strip and shifT" function.
2023-08-22 07:55:25 <KipIngram   > Well, I think you will if you think about it.
2023-08-22 07:55:41 <veltas      > I can guess but I'm not sure
2023-08-22 07:55:52 <KipIngram   > The two options are for my NEXT code to check and see if it's time to fetch the next cell, or just let it happen naturally by getting a 0b000000 instruction.
2023-08-22 07:56:33 <KipIngram   > I want the fastest, simplest NEXT possible, and that's to ONLY pull off the low order six bits and downshift, and then jump through my jump table.
2023-08-22 07:56:56 <KipIngram   > Just think about how you'd implement next in the two different ways.
2023-08-22 07:57:24 <KipIngram   > NEXT is basically going to pretend that the instruction word is infinite and that I can just keep on shifting new bits down.
2023-08-22 07:57:42 <KipIngram   > The transistion to the next cell will be handled not by NEXT but by an instruction execution instead.
2023-08-22 07:58:30 <KipIngram   > I'm not going to have any awareness of how much of a cell I've executed so far.
2023-08-22 07:59:13 <KipIngram   > The "loop invariant" for NEXT is that the next instruction to execute will be in the low order six bits.
2023-08-22 08:00:26 <KipIngram   > I think I'll actually have to use both 0b000000 and 0b111111 for that operation, because in order to keep the "remaining bits" representing a valid signed constant I need to use arithmetic right shift.
2023-08-22 08:00:35 <veltas      > What is this VM going to run in? Is this going to be programmed to an FPGA?
2023-08-22 08:00:41 <KipIngram   > So if the cell has 1 in the MSB, then 1's will feed in on shifts.
2023-08-22 08:01:09 <KipIngram   > No, I'll have a bunch of machine code bits to implement the instructions, and will reach them through a 64-entry jump table.
2023-08-22 08:01:19 <KipIngram   > It's kind of like a six-bit token threaded system.
2023-08-22 08:01:24 <veltas      > So you're writing this in assembly?
2023-08-22 08:01:43 <KipIngram   > Yes, basically.  The vm portion at least.
2023-08-22 08:01:51 <veltas      > It's pretty much just a packed token forth
2023-08-22 08:01:51 <KipIngram   > NEXT will look basically like this:
2023-08-22 08:02:50 <veltas      > In ilo's x86-64 port I had four decodes written in sequence as function calls, so I used the return address to keep track of how much had been decoded
2023-08-22 08:02:53 <KipIngram   > mov regB, regA ; sar regA, 6 ; and regB, 0x3F ; jmp [regC+4*regB]
2023-08-22 08:03:11 <KipIngram   > regA is instruction word, regB is scratch, regC points to the table.
2023-08-22 08:03:23 <veltas      > And I kept the remaining decoded opcode in a register
2023-08-22 08:03:48 <KipIngram   > I'll use jumps rather than calls.
2023-08-22 08:04:24 <KipIngram   > I only need to fetch a new cell when I'm pulling out the last instruction of a slot, and I will eventually ALWAYS get either 0b000000 or 0b111111 if I just keep going.
2023-08-22 08:04:32 <KipIngram   > So those can cause the new fetch.
2023-08-22 08:05:02 <KipIngram   > So I guess I really only get two instructions for free use in that "short slot."
2023-08-22 08:05:15 <veltas      > How do you return to decode, do the machine code bits end with "jmp decode" or something?
2023-08-22 08:05:18 <KipIngram   > 0b000001 and 0b000010
2023-08-22 08:05:48 <KipIngram   > Either that or just include NEXT at the end of each bit of machine code.
2023-08-22 08:06:04 <veltas      > And I suppose the most common operation can 'fall' into the decode routine
2023-08-22 08:06:24 <KipIngram   > Yeah, if I use jmp elsewhere.
2023-08-22 08:06:38 <KipIngram   > Thing is, I like doing those jumps with a register, so that would consume a register to point to NEXT.
2023-08-22 08:06:59 <KipIngram   > In my current system all primitives end with jmp r15.
2023-08-22 08:07:13 <veltas      > Not sure what impact that has on branch prediction etc
2023-08-22 08:07:30 <KipIngram   > I see your point.
2023-08-22 08:07:32 <veltas      > I'd expect it to predict but it might have some pipeline overhead
2023-08-22 08:07:42 <KipIngram   > I could time it both ways.
2023-08-22 08:07:50 <KipIngram   > It's a macro, so it's easy to change.
2023-08-22 08:07:53 <veltas      > Profiling is the best shout
2023-08-22 08:08:00 <KipIngram   > You're right, though, it's a valid question.
2023-08-22 08:08:17 <KipIngram   > I hadn't thought about it that way - it's always hard for me to not fall into thinking that "shorter is faster.'
2023-08-22 08:08:31 <veltas      > Well usually that's a good metric
2023-08-22 08:08:32 <KipIngram   > I'm old and learned most of that stuff back before things were so complicated.
2023-08-22 08:09:26 <KipIngram   > I hadn't even thought about it that way, but  yeah - a register jump isn't necessarily always the same.  The processor can't KNOW that the register hasn't changed.
2023-08-22 08:09:40 <KipIngram   > Although with register renaming and all, maybe it could.
2023-08-22 08:09:47 <KipIngram   > It's aware of when it renames registers.
2023-08-22 08:10:06 <KipIngram   > so it might be aware that that register never changed.
2023-08-22 08:10:09 <veltas      > Yeah it does know if it's changed, but I think that worrying about this might add overhead
2023-08-22 08:10:24 <KipIngram   > Yeah.  I'll measure it later today.
2023-08-22 08:10:31 <KipIngram   > Easy to do.
2023-08-22 08:10:31 <veltas      > It doesn't add any overhead at all if it's just a relative immediate jump
2023-08-22 08:11:27 <KipIngram   > I've gotten kind of psyched at how small this system's going to be.
2023-08-22 08:11:31 <veltas      > Nice
2023-08-22 08:11:33 <KipIngram   > Everything about it is "compact."
2023-08-22 08:11:43 <veltas      > I do like tokenised stuff and memory optimisation, I'm a sucker for that stuff
2023-08-22 08:11:58 <KipIngram   > Especially since I'm returning to old fashioned inline headers with defintiion bodies immediately following the header.
2023-08-22 08:12:13 <veltas      > It's why my forth for ZX Spectrum supports tokenisation as a build option, it's just too cool not to have, even though it's slower
2023-08-22 08:12:21 <veltas      > Yeah
2023-08-22 08:12:27 <KipIngram   > It will mean that words are not naturally re-vectorable, though.
2023-08-22 08:12:39 <KipIngram   > I'll have to implement that special for words that I want to be able to do that with.
2023-08-22 08:13:49 <veltas      > Already the case in most forths anyway
2023-08-22 08:13:57 <KipIngram   > Anyway, the last real instruction in a cell is allowed to take the whole rest of the cell as an operand.  At the time I execute that instruction, the cell has been shifted down so that the operand is in the LSB position.
2023-08-22 08:14:14 <KipIngram   > And like I said, in order to make that be a signed operand, I need to use arithmetic right shift.
2023-08-22 08:14:37 <KipIngram   > So I don't know if the "post cell" instruction will be all 0's or all 1's.
2023-08-22 08:15:38 <KipIngram   > When I don't get to use those last two bits as an instruction, I can have them be 00.
2023-08-22 08:15:51 <KipIngram   > But if an instruction does  fit there, the MSB might be either sign.
2023-08-22 08:16:36 <KipIngram   > I'll probably let return be one of those instructions for sure, and the other either unext or literal.
2023-08-22 08:17:29 <KipIngram   > I dont really need a nop instruction.
2023-08-22 08:17:49 <KipIngram   > Chuck had that because he needed to kill time once in a while.
2023-08-22 08:22:51 <veltas      > You have other NOP's available
2023-08-22 08:23:12 <veltas      > Like 0 DROP etc
2023-08-22 08:36:52 <MrMobius    > could you have a register hold your NEXT pointer so every primitive ends with 'jmp reg' then have 4 NEXTs
2023-08-22 08:37:11 <MrMobius    > where each loads the pointer reg with a pointer to the next
2023-08-22 08:37:25 <MrMobius    > and one of the four loads a new instruction
2023-08-22 08:38:31 <MrMobius    > but the four are otherwise identical
2023-08-22 08:41:05 <MrMobius    > MIPS and therefore almost certainly RISC-V has an instruction to extract a run of bits from one reg into another which can replace shift and mask
2023-08-22 08:41:28 <MrMobius    > dunno about M0 or Aarch64 but might be worth checking
2023-08-22 08:43:00 <veltas      > I know there's a facility for this in PPC
2023-08-22 08:43:47 <veltas      > https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-instruction-set/bitfield-instructions/sbfx-and-ubfx
2023-08-22 08:48:17 <MrMobius    > ya exactly
2023-08-22 08:48:43 <MrMobius    > doesn't look like it made it into the M0 though which is what I think KipIngram's contraption has
2023-08-22 08:48:45 <MrMobius    > https://developer.arm.com/documentation/ddi0432/c/programmers-model/instruction-set-summary
2023-08-22 08:49:00 <veltas      > I think UBFX is in M0, might be SBFX as well
2023-08-22 08:49:46 <veltas      > Not sure actually, don't quote me on that
2023-08-22 08:51:38 <veltas      > Nope https://developer.arm.com/documentation/ddi0432/c/programmers-model/instruction-set-summary
2023-08-22 08:51:49 <veltas      > Oh you literally just posted that
2023-08-22 08:51:57 <veltas      > Sorry didn't see :)
2023-08-22 08:52:15 <veltas      > I won't lie I have a lot of trouble with ARM's website
2023-08-22 08:55:25 <KipIngram   > MrMobius: The 32655 has an M4, I believe.
2023-08-22 08:55:54 <veltas      > KipIngram's bought a relatively advanced chip
2023-08-22 08:55:55 <KipIngram   > I haven't researched the optimum way to do the shift and mask yet.
2023-08-22 08:56:05 <MrMobius    > veltas: lol
2023-08-22 08:56:14 <veltas      > I was going to buy an M0 though
2023-08-22 08:56:19 <KipIngram   > I was just laying out the operations as they'd look on x64.
2023-08-22 08:56:28 <veltas      > I find it interesting the M0 supports 32-bit multiply
2023-08-22 08:57:16 <veltas      > Oh but it can take 32 cycles
2023-08-22 08:57:33 <veltas      > That's the catch then, it's designed to allow for microcode implementation
2023-08-22 08:57:41 <veltas      > But it's still better than implementing yourself
2023-08-22 08:57:45 <MrMobius    > ya there are two multiply options
2023-08-22 08:57:54 <MrMobius    > for M0
2023-08-22 08:57:59 <veltas      > 32 cycles is pretty good still
2023-08-22 08:58:21 <MrMobius    > definitely for small embedded stuff
2023-08-22 08:58:26 <KipIngram   > It is, considering that essentially a 32 bit multiply has to do 32 adds.
2023-08-22 08:58:41 <KipIngram   > potentially
2023-08-22 09:01:35 <veltas      > Outputting dots for unprintable characters in listings makes it much more obvious which blocks haven't been WIPE'd yet
2023-08-22 09:15:30 <KipIngram   > I noticed that the ARM instruction set allowed a lot of "combinin of things" (shifts applied along with other operations, etc.)  I'm not sure how well that will get supported in a Forth, though - it kind of looks like you'd need to craft the instructions to what you were doing, and Forth words are somewhat "generic."
2023-08-22 09:16:09 <KipIngram   > I.e., you're doing your  "mixing" at the Forth source level; each Forth word needs to do something pretty "pure.'
2023-08-22 09:16:38 <KipIngram   > A true code-threaded system might give you the opportunity to capture some of that.
2023-08-22 09:16:59 <KipIngram   > But what I'm writing isn't like that - it's code threaded, but at the vm level.
2023-08-22 09:18:54 <MrMobius    > ya seems like you cant take much advantage of that unless you're willing to generate optimized machine code like mecrisp
2023-08-22 09:19:05 <KipIngram   > Right - exactly.
2023-08-22 09:20:08 <KipIngram   > I guess this is really a token-threaded system, but it sure does have some attributes of a code threaded system.
2023-08-22 09:21:58 <veltas      > I think you can get a lot with some of the simpler mecrisp optimisations
2023-08-22 09:22:19 <veltas      > Like inlining, using TOS register, would allow some of those combinations to be a bit easier
2023-08-22 09:22:31 <KipIngram   > I really like mecrisp.  I've not used it, but just reading about it it seems like a really well thought out tool.
2023-08-22 09:23:24 <veltas      > If I was you I would read the mecrisp source for the platform you're porting to
2023-08-22 09:23:35 <KipIngram   > That's a good idea.
2023-08-22 09:24:10 <KipIngram   > I'm focused mostly  on the system-level implementation right now, though - using my vm instructions to implement the bulk of the system.
2023-08-22 09:24:29 <KipIngram   > I'll get around to the vm at some point, though, and I think something like that would definitely be useful.
2023-08-22 09:25:19 <KipIngram   > Functionally, though, the vm seems like it's going to be pretty simple.
2023-08-22 09:25:25 <veltas      > VM is a good idea too
2023-08-22 09:32:51 <KipIngram   > Yeah, I just changed my next macro from jmp rrNEXT to jmp next_c, and the system still ran fine.
2023-08-22 09:33:19 <KipIngram   > So that will be as simple to profile as I thought.
2023-08-22 09:34:22 <veltas      > Yeah I wonder how it will run on x86 vs M4
2023-08-22 09:34:34 <KipIngram   > So I had talked about putting my timer tick / thread swap stuff into docol.
2023-08-22 09:34:48 <KipIngram   > I think the equivalent here will be to put it in the table code handling call.
2023-08-22 09:35:13 <veltas      > Does the platform have no interrupt stuff you could use?
2023-08-22 09:36:07 <KipIngram   > I'm sure it does, but I don't want that stuff to happen just anywhere.  I want vm instructions to be atomic, for one thing, and in the precise model I was looking at before *primitives* were atomic.
2023-08-22 09:36:55 <KipIngram   > On the 32655 I'll probably set it up so that interrupts trigger Forth routines - the vm's machine code will just note the interrupt and arrange the next thread switch to run the handler.
2023-08-22 09:37:28 <KipIngram   > Don't know for sure yet, but "extreme real time" isn't really my goal here.  I think "kinda sorta real time" will suit me.
2023-08-22 09:40:04 <KipIngram   > If I put the thread switching in call then sequencies of vm instructions will run atomically.
2023-08-22 09:41:46 <KipIngram   > Which is good, because otherwise the interrupt handler would have to save the in-progress instruction word as the return address.
2023-08-22 09:42:16 <KipIngram   > I thought about trying to allow call to use just part of the remaining cell, and come back to it after, but rejected that for the same reason - it just complicates the call return mechanism.
2023-08-22 09:42:39 <KipIngram   > Once I start on a cell, I have to finish it.
2023-08-22 09:43:41 <KipIngram   > The other option is to have the thread swap be done in that 0b000000/0b111111 bit that reloads the instruction word.
2023-08-22 09:43:55 <KipIngram   > That may make more sense that call - then I'm cell atomic, pure and simple.
2023-08-22 09:44:38 <KipIngram   > That will include cells that microloop, so I'll have to be careful about that - handling such a cell could take a long time, dependingon the microloop.
2023-08-22 09:44:56 <KipIngram   > I'll just have to know not to abuse that.
2023-08-22 12:10:35 <KipIngram   > I think I will put the thread check into the call code, not into the new cell code.  I think there's a good argument for the new cell code, but the problem with that is that exactly where cell boundaries fall can be affected by changing code arbitrarily far away.  So I could have something working great, then make a small code change somewhere entirely different, and suddenly have a race condition.
2023-08-22 12:10:50 <KipIngram   > If the thread check was in the new cell code, that is.
2023-08-22 12:11:01 <KipIngram   > But if it's in the call code, well, that won't change in the same arbitrary way.
2023-08-22 12:15:34 <KipIngram   > I'd rather not have something in the system that makes exactly where cell boundaries happen to fall a potential issue.
2023-08-22 12:16:37 <KipIngram   > Wait - actually, maybe that's not an issue.  At least not one as arbitrary as I was implying.  Every definition will be aligned to start on a cell boundary.  So it would at least have to be a code change in the same definition.
2023-08-22 12:17:00 <KipIngram   > Still a valid possibility, but the "arbitrarily far away" part goes away.
2023-08-22 12:47:06 <MrMobius    > could you use pointers and swap them out in an interrupt so you have a separate stack the way some processors have a whole different set of registers for interrupts?
2023-08-22 12:58:54 <KipIngram   > Potentially.  If I wanted to I could, I guess.
2023-08-22 12:59:12 <KipIngram   > Isn't that primarily for security, though?  An ISR shouldn't leave the stack unbalanced.
2023-08-22 12:59:21 <KipIngram   > I need to drive into the office - back in a bit.
2023-08-22 13:17:25 <MrMobius    > I think it's for speed in the interrupt handler so you don't have to push any registers
2023-08-22 13:18:07 <MrMobius    > you wouldn't have to worry about the stack at the end of the ISR since it should be wiped anyway
2023-08-22 13:23:21 <Zarutian_iPad> 
ACTION is looking into the feasibility of adding an RRRRGGGGBBBBHV pin header to VERA for connecting to RGBtoHDMI setup

2023-08-22 13:38:48 <Zarutian_iPad> regarding ?stream i/o? in Forth
2023-08-22 13:40:18 <Zarutian_iPad> lets say I am implementing ROT13 "cipher", is it a good enough idea to pass in a few xt's?
2023-08-22 13:41:27 <Zarutian_iPad> say three: one xt for it to get a byte, one xt to output a byte, and one xt for error raising
2023-08-22 13:42:09 <Zarutian_iPad> or am I entering into co-routine territory here?
2023-08-22 15:42:26 <KipIngram   > MrMobius: Ok.  Well, if the processor offers me an opportunity to do work in an ISR without having to save a bunch of registers, that would be ood.
2023-08-22 15:42:31 <KipIngram   > good
2023-08-22 15:42:44 <KipIngram   > But I don't really see a use for an alternate stack.
2023-08-22 15:42:53 <veltas      > The Z80's shadow registers are for that
2023-08-22 15:43:14 <KipIngram   > I'm going to have a stack for each thread of course, but other than that I'll just use whatever stack is handy and keep it balanced.
2023-08-22 15:43:19 <MrMobius    > I mean the alternate stack would be where you run forth code in an ISR
2023-08-22 15:43:23 <veltas      > KipIngram: The use of alternate stack is reservation. If you say the stack is 40 deep but you share the same stack then really it's 40-N deep where N is max depth of interrupt
2023-08-22 17:53:49 <veltas      > I've been using gforth for years but it wasn't until someone asked that I bothered to find out about more.fs