2023-01-21 10:58:13 <KipIngram   > You know, the more I think about this "loopback" mechanism I've talked about recently, the more I like it.
2023-01-21 10:58:44 <KipIngram   > It just seems very clean to me, and it removes the need for jumps to be "special" by needing an offset compiled after them.
2023-01-21 10:58:57 <KipIngram   > They just become dirt simple Forth primitives that are just like all the others.
2023-01-21 10:59:14 <KipIngram   > And it's *really* easy to implement.
2023-01-21 10:59:45 <KipIngram   > You would still need a normal jump operation, because you need it for tail optimization.
2023-01-21 11:00:01 <KipIngram   > I haven't thought of any way out of that yet.
2023-01-21 11:00:41 <KipIngram   > In my hardware that's no problem - I can use a value of those two "leftover bits" to specify whether or not a control transfer gets a return stack push or not.
2023-01-21 11:00:57 <KipIngram   > But in a software implementation it still looks like you'd need a "jump" word with the target after it.
2023-01-21 11:02:23 <KipIngram   > I also like how the mechanism enforces a "standard" programming style.
2023-01-21 11:02:55 <KipIngram   > You can loop back to an earlier point in your word.  That point begins at the beginning of the word, but you can advance it forward if you want to (but you can't move it backward).
2023-01-21 11:03:11 <KipIngram   > And that's the only kind of loop you have.
2023-01-21 11:03:47 <KipIngram   > Someone might complain that you can't nest loops (unless they share a beginning), but I call that a feature - it forces you to factor.
2023-01-21 11:05:16 <KipIngram   > It adds one machine instruction to docol, and that is the only speed penalty.  Well, if you want to advance the jump point forward, that costs one primitive.  But it's not "inside" your loop - you'd only pay it once.
2023-01-21 11:05:45 <KipIngram   > You could spare that one instruction in docol too, if you wanted to, but then the jump point would be uninitialized.
2023-01-21 11:06:44 <KipIngram   > With this mechanism, though, I'd no longer need that extra bit in my header that specifies compilation of an offset after a word.
2023-01-21 11:09:56 <KipIngram   > I think this is going into everything I do from here on out.
2023-01-21 11:12:40 <KipIngram   > I'm also giving serious thought to separating my code and parameter field pointers from my headers.  I'd put them in a table that contained only t hem instead.
2023-01-21 11:12:56 <KipIngram   > Headers would have an index into that table.
2023-01-21 11:13:29 <KipIngram   > This would let the header section be something I could completely decaptitate without impairing the system's ability to run compiled code.
2023-01-21 11:14:01 <KipIngram   > And by packing all those pointers into the smallest possible region, it lets me consider using 16-bit xt's in my definitions.
2023-01-21 11:14:25 <KipIngram   > That would support up to 64k words, but the implementations of everything could be as large as necessary.
2023-01-21 11:14:47 <KipIngram   > So that would reduce my code size a lot - by almost a factor of two.
2023-01-21 11:17:01 <KipIngram   > So the headers would just become a completely separate affair, and it would be a lot easier to do a tethered system or something like that if I wanted to.
2023-01-21 11:17:54 <KipIngram   > I'd likely design such a system right from the start to have good support for cross-compiling; the idea of multiple image spaces would be wired in.
2023-01-21 11:22:00 <KipIngram   > So, looks like I'm about to start a new one.  :-)
2023-01-21 11:27:09 <KipIngram   > I'll probably put the table at the bottom of the image.  It'll get some initial size, but it would be easy to move the stuff above it and update all the pointers, because in this design we know exactly where they all are.
2023-01-21 11:27:52 <KipIngram   > So for making a system for some device, you'd just squash it down when you were done - squeeze out any leftover table room.
2023-01-21 11:29:19 <KipIngram   > Technically primitives don't need the second pointer, but a lot of advantages would be lost if I didn't have them in the table anyway - then it would be hard to tell code pointers from body pointers.
2023-01-21 11:34:22 <KipIngram   > Maybe it would be ok to put two primitive pointers in a table pair.
2023-01-21 11:35:26 <veltas      > Yeah it's an interesting idea (loopback)
2023-01-21 11:35:42 <veltas      > I've said before it might be interesting to have a Forth where definitions are ended by line end
2023-01-21 11:36:34 <veltas      > Maybe at the VM level you could have all words starting on an alignment, and then your loopback instruction just goes back to the current def
2023-01-21 11:36:41 <veltas      > So defs can only be a certain fixed length each
2023-01-21 11:36:52 <veltas      > Then no immediate is needed
2023-01-21 11:37:47 <KipIngram   > Yeah, I see what you're getting at.  Same idea, but without actually needing to "remember" an address.
2023-01-21 11:38:13 <KipIngram   > That's kind of what I'm doiing now works at the compiler level - the "me" words just automatically target the beginning of the definition.
2023-01-21 11:38:29 <KipIngram   > At the code level I have to figure out where that is, but at the source level it's transparent.
2023-01-21 11:38:49 <KipIngram   > I only recently thought about the idea of being able to shift it forward.
2023-01-21 11:39:09 <KipIngram   > In my current system the "philosophy" is that "me" words target the start of the most recent word.
2023-01-21 11:39:24 <KipIngram   > The most recent : def.
2023-01-21 11:39:39 <KipIngram   > That led me to pick the word name :. for the "move forwardd" operation.
2023-01-21 11:39:47 <KipIngram   > Sort of a "dummy : def" thing.
2023-01-21 11:40:25 <KipIngram   > :* might be a reasonable  name too.
2023-01-21 11:43:07 <KipIngram   > I'm trying to decide right now whether I want machine code completely separated from the bodies of definitions.  It's kind of pleasing to me to have all my code in one lump, but on the other hand : definition lists are actually "code" too, so lumping them all together might be ok as well.
2023-01-21 11:43:22 <KipIngram   > I'm just wondering wheether keeping code separate might improve cache performance or something.
2023-01-21 11:43:27 <KipIngram   > What do you think?
2023-01-21 11:44:01 <KipIngram   > Also code doesn't have the same kind of alignment requirements that lists of xt's would.
2023-01-21 11:45:08 <KipIngram   > But if I separate them it's another region to manage.
2023-01-21 11:45:29 <veltas      > > "me" words
2023-01-21 11:45:32 <veltas      > What words?
2023-01-21 11:45:33 <KipIngram   > Another thing to shift when I needed more room or wanted to compact things.
2023-01-21 11:45:45 <KipIngram   > Those are my conditional and unconditional looping words.
2023-01-21 11:45:51 <KipIngram   > "recurse"
2023-01-21 11:46:11 <KipIngram   > I have plain me and also things like 0<=me and so on.
2023-01-21 11:46:13 <veltas      > What is a move forward operation?
2023-01-21 11:46:30 <KipIngram   > Well, I'm talking about this table of pointers being a separate region of RAM.
2023-01-21 11:46:51 <KipIngram   > I have to put it somewhere.  Like say the table is in low addresses and the def lists are above it.
2023-01-21 11:47:04 <KipIngram   > I might run out of room, in which case I'd want to shift all the def lists up to make more table space.
2023-01-21 11:47:19 <KipIngram   > And then I'd have to run through the table and adjust all of the pointers accordingly.
2023-01-21 11:47:35 <KipIngram   > Or, if I finish work on an embedded design and have a bunch of empty table space.
2023-01-21 11:47:48 <KipIngram   > Id want to move the lists down to squeeze that space out, and adjust the pointers.
2023-01-21 11:48:14 <KipIngram   > Because what the table IS is a collection of pointers into the body region.
2023-01-21 11:48:52 <veltas      > So what happens when you use :. or rather where would you use it in a definition?
2023-01-21 11:49:47 <KipIngram   > Ok, so what I'm picturing is that docol will push IP to the return stack as usual.  But it will also allocate a second cell in that operation (so two new return stack cells), and the extra one will be initialized to p oint to the beginning of the new definition.
2023-01-21 11:50:02 <KipIngram   > Then me and its friends would jump back to beginning of def, by just loading IP from that extra cell.
2023-01-21 11:50:19 <KipIngram   > :. would just overwrite that cell with the current IP, moving the target for me words forward.
2023-01-21 11:50:35 <veltas      > Okay
2023-01-21 11:51:03 <veltas      > I think I prefer encoding other distances at runtime, this reminds me of the DO...LOOP LEAVE workaround
2023-01-21 11:51:06 <KipIngram   > So the me words would be an awful lot like normal returns, except they wouldn't actually pop the return stack.
2023-01-21 11:51:26 <veltas      > Sorry I mean prefer encoding the distances in the binary, not keeping track at runtime
2023-01-21 11:51:42 <KipIngram   > Sure - I may think about this more and decide it has shortcomings.  It's just kind of two ways of doing the same thing.
2023-01-21 11:51:57 <KipIngram   > Encoding the jump distances is more flexible, of course - you can do everything with no constraints at all.
2023-01-21 11:52:14 <KipIngram   > This system has limitations.  Only one "current jump target" per definition, etc.
2023-01-21 11:52:34 <KipIngram   > But that's the way I've been coding for a while  now, and I haven't felt at a loss.
2023-01-21 11:52:58 <KipIngram   > It's not implemented the way I've described this morning - I actually do use encoded jump offsets.
2023-01-21 11:53:11 <KipIngram   > But I've been limiting myself to this "jump back to start of def only" style.
2023-01-21 11:53:27 <veltas      > I like the purity of colon definitions being fixed length but it's very wasteful
2023-01-21 11:53:32 <KipIngram   > I use the dictionary at compile time to discover where that is.
2023-01-21 11:53:33 <veltas      > Only as wasteful as blocks though I suppose
2023-01-21 11:53:56 <KipIngram   > Yeah, I'm probably not going to do that.  Using the extra return stack cell appeals to me more.
2023-01-21 11:54:03 <KipIngram   > But I do see what you like about it.
2023-01-21 11:54:15 <KipIngram   > I was thinking a little about sectorforth this mo rning, and had a similar thought.
2023-01-21 11:54:19 <veltas      > I would just encode a relative backwards jump with 8-bit immediate
2023-01-21 11:54:30 <KipIngram   > I was thinking about that first way it works, where you just take a char from stdin and act on it.
2023-01-21 11:54:44 <KipIngram   > That could be done in a similar way - just compute an address from the char and jump there.
2023-01-21 11:54:55 <KipIngram   > So each char handler would have to be on evenly spaced increments.
2023-01-21 11:55:11 <KipIngram   > You could recover some of that waste - you could always jump into a " wasted" area from somewhere else.
2023-01-21 11:55:22 <KipIngram   > But that kind of spaghettifies the code.
2023-01-21 11:55:43 <veltas      > I'm personally a fan of spaghetti
2023-01-21 11:55:57 <KipIngram   > That wouldn't really work for sectorforth, though, because you wouldn't actually have a *dictionary*.
2023-01-21 11:56:05 <KipIngram   > So it would be hard to add to it.
2023-01-21 11:56:38 <KipIngram   > I also want to get the portability aspects right this go round.
2023-01-21 11:56:54 <KipIngram   > Make sure I use only a set of well-thought-out macros to implement primitives with.
2023-01-21 11:56:54 <veltas      > The smallest bootstrap forth is probably just interpret numbers and the C, word
2023-01-21 11:57:02 <KipIngram   > Those would be my "virtual instructions."
2023-01-21 11:57:04 <veltas      > And then you have to add your own defs via C, at first
2023-01-21 11:57:21 <KipIngram   > The idea would be you could implement them with good efficiency in a variety of platform instruction sets.
2023-01-21 11:57:44 <KipIngram   > Yeah, that probably is the smallest.
2023-01-21 11:58:06 <KipIngram   > But then you'd need to deal directly with the system's instruction set, right?
2023-01-21 11:58:24 <veltas      > You already pretty much need to in sectorforth
2023-01-21 11:58:33 <KipIngram   > Yeah, I guess o.
2023-01-21 11:58:35 <KipIngram   > so
2023-01-21 11:58:57 <veltas      > IMO SectorForth is so small that it stops being a useful Forth, but it's still a useful exercise
2023-01-21 11:59:08 <KipIngram   > What I want is to only have to port those macros to a new platform, and then just feed it my source code and wind up with a good system.
2023-01-21 11:59:32 <veltas      > That's what crc's got
2023-01-21 11:59:36 <KipIngram   > We all know you can push that idea way down - maybe wind up with a dozen or less macros, but then you probably can't get good efficiency.
2023-01-21 11:59:53 <KipIngram   > So I'm hoping for a "few dozen."  Maybe 40 or so, or something like that.
2023-01-21 12:00:06 <veltas      > Have you considered using one of crc's VMs
2023-01-21 12:00:15 <KipIngram   > I figure how well that turns out in the end, performance wise, on various platforms depends a lot on how well I choose those macros.
2023-01-21 12:00:20 <veltas      > Then there is possiblity of some kind of interesting collab
2023-01-21 12:00:35 <KipIngram   > No, a lot of the fun I get from this kind of thing is inventing it myself.
2023-01-21 12:00:50 <KipIngram   > I'm happy to copy ideas and concepts, but I don't really want to just take someone else's details.
2023-01-21 12:01:12 <veltas      > Do you use ASCII?
2023-01-21 12:01:31 <KipIngram   > Generally, yeah, though I've kind of gotten into the idea of at least coping with UTF8.
2023-01-21 12:01:41 <veltas      > I'm making a silly point :P
2023-01-21 12:01:49 <veltas      > That ASCII is someone else's details
2023-01-21 12:01:50 <KipIngram   > Oh, oh - gotcha.   :-)
2023-01-21 12:01:54 <KipIngram   > Fair point.
2023-01-21 12:01:57 <veltas      > It's up to you what you copy
2023-01-21 12:02:07 <veltas      > Chuck has his own encoding
2023-01-21 12:02:08 <KipIngram   > So I guess I don't take it THAT far.
2023-01-21 12:02:18 <KipIngram   > Sure, I could look over his stuff and use it to spur my thinking.
2023-01-21 12:02:22 <crc         > re: portability; I inevitably end up with around 30-40 fundamental primitives in my designs
2023-01-21 12:02:37 <KipIngram   > Ok, good - that's where I'm hoping to land.
2023-01-21 12:02:47 <veltas      > So maybe have a look anyway
2023-01-21 12:02:49 <crc         > less is possible, but I find performance to suffer as the primitives drop
2023-01-21 12:02:50 <veltas      > Don't have to copy
2023-01-21 12:03:00 <veltas      > Check's first codes are: 0123456789abcdefghijklmnopqrstuvwxyz
2023-01-21 12:03:10 <veltas      > So you can convert to base digits without an offset
2023-01-21 12:03:15 <KipIngram   > Yes, that's what I'd expect.  That feels like about the point where you'd start to get reasonable performance.
2023-01-21 12:04:09 <crc         > veltas: I'd be doing that if I didn't want to maintain any sort of easy interoperability with external stuff
2023-01-21 12:04:17 <KipIngram   > I do want to have something that will run under Linux, even t hough I have aspirations for embedded applications.  That's really kind fo the incentive to work with ASCII.
2023-01-21 12:04:28 <KipIngram   > Otherwise I'll face some conversion processes.
2023-01-21 12:05:44 <KipIngram   > crc: Do you intermingle lowest level vm instructions with definition lists, or do they go in separate ranges?
2023-01-21 12:06:02 <KipIngram   > primitive implementations and definition implementations.
2023-01-21 12:06:31 <veltas      > I do like that Forth has its own base64-style encoding with #36 BASE !
2023-01-21 12:06:48 <veltas      > There are a few things in Forth that are way ahead of its time
2023-01-21 12:06:54 <KipIngram   > Oh yeah.
2023-01-21 12:07:06 <crc         > I intermingle. I have a dedicated region of memory for various systems use (block buffer, tib, temporary strings & array buffers), but everything else is intermingled
2023-01-21 12:08:13 <veltas      > I think any 'professional' feature-rich Forth should support separating the dictionary and the interpreter out completely, for security and also to lock down the code a bit more
2023-01-21 12:08:26 <veltas      > And hide all word names etc
2023-01-21 12:08:42 <KipIngram   > Yes.  I was heading in that direction on my current system, but I didn't really take it far enough.
2023-01-21 12:09:08 <KipIngram   > Headers are separated from implemntations, but the implementations point back into header zone, because that's where the pointer pairs are.
2023-01-21 12:09:20 <KipIngram   > So this time I want to move those out of the headers and into this table zone.
2023-01-21 12:09:29 <KipIngram   > Which will be formally part of an "image."
2023-01-21 12:09:43 <KipIngram   > Nothing will point back to the headers.
2023-01-21 12:10:12 <KipIngram   > Unless maybe it's LATEST; I'll have to decide how to manage that.
2023-01-21 12:10:44 <veltas      > Yeah being able to generate an image is pretty important too
2023-01-21 12:10:48 <veltas      > To a fat Forth
2023-01-21 12:10:56 <veltas      > A minimal Forth I wouldn't expect it
2023-01-21 12:11:01 <KipIngram   > I have to have it if I'm going to do all the future things I want to do.
2023-01-21 12:11:38 <KipIngram   > Maybe the best way to handle LATEST would be for the header zone to use indices too.  So there would be a pointer table there as well, to the details of that header.
2023-01-21 12:12:22 <KipIngram   > Then headers would match up with bodies by sharing an index.
2023-01-21 12:14:17 <KipIngram   > crc: Are you endian flexible, or did you commit to something on that?
2023-01-21 12:14:28 <KipIngram   > How about cell size?
2023-01-21 12:15:02 <crc         > My on-disk storage format for the image & data is little endian
2023-01-21 12:15:17 <veltas      > But otherwise being word-addressed it's mostly without endianness
2023-01-21 12:15:33 <KipIngram   > Ok.  What I meant was can  you easily crank out a system for little endian or big endian processors?
2023-01-21 12:15:36 <crc         > In my little system, 32-bit cells. The larger one can be compiled with either 32 or 64 bit cells
2023-01-21 12:15:44 <crc         > Yes
2023-01-21 12:15:51 <KipIngram   > Nice.  :-)
2023-01-21 12:16:22 <KipIngram   > I don't count the disk storage as any kind of limitation; that's under your control.
2023-01-21 12:17:45 <crc         > I have mine running on 68k (big endian, Mac system 5, 6, or 7) and Java VM (also big  endian)
2023-01-21 12:18:56 <crc         > veltas is correct in that since I use a word-addressed system, once loaded the endian doesn't really matter
2023-01-21 12:19:14 <MrMobius    > crc, neat. what 68k system?
2023-01-21 12:19:51 <crc         > MrMobius: classic mac computers (tested under system 5, 6, and 7)
2023-01-21 12:25:21 <KipIngram   > Oh, in a system like this I could implement .: .wipe fully again.
2023-01-21 12:25:49 <KipIngram   > I could always delete a header record by moving everything above it down and adjusting the relevant pointers in the header zone table.
2023-01-21 12:26:06 <KipIngram   > Having these tables has the very nice feature of knowing exactly where all of the pointers are.
2023-01-21 12:26:48 <KipIngram   > I could choose whether to do that are not - sometimes I might not want to, for decompilation reasons.
2023-01-21 12:32:14 <MrMobius    > one of the benefits of a primitive type system is you know where all the pointers are and can adjust them when necessary
2023-01-21 12:32:21 <MrMobius    > so garbage collection for example becomes easy
2023-01-21 12:50:48 <KipIngram   > I think I'd want to distinguish in this system between "regular" variables that hold application values etc. and "system" variables that, for example, point to spots in the dictionary.  Thinks like DP and so on.  Regular variables would have an address in body space and the value would be store there.
2023-01-21 12:51:07 <KipIngram   > System variables would keep the value in the table, so that they got updated properly when I moved things around.
2023-01-21 12:51:32 <KipIngram   > Regular variables would be 64 bits in a 64-bit system, but table cells will be 32 (because that's enough for anything I imagine doing).
2023-01-21 12:52:07 <KipIngram   > So : here  dp h@ ;
2023-01-21 12:53:46 <KipIngram   > Even though I'm trying to separate headers completely, I'll still want words that I use to access the header region.  So the system will need to know where the headers *would be*, if they are available from the body.
2023-01-21 12:54:13 <KipIngram   > Such words just wouldn't be included in a target cross-compile.
2023-01-21 12:54:34 <KipIngram   > Unless the intent was to have headers present on that system as well.
2023-01-21 12:55:42 <KipIngram   > Which raises an interesting point.  Cross compiling a full Forth system, that you intend to run as Forth on the target, needs to make target headers.  Cross-compiling an embedded application for some device doesn't.
2023-01-21 14:32:40 <veltas      > Things are getting very lispy when you only allow looping back to the start of the function
2023-01-21 14:33:05 <veltas      > Old-school lisp stuff is very recursion-based and refuses other constructs
2023-01-21 14:33:20 <veltas      > Or at least one school, not sure about old-school
2023-01-21 14:33:32 <veltas      > Not necesarily a bad thing
2023-01-21 14:34:09 <KipIngram   > Right.  Well, that's how I've been operating, but I can put a : def anywhere I want in my code, so at the cost of a new header entry I can loop back to anywhere.
2023-01-21 14:34:23 <KipIngram   > The purpose of :. is to get that capability without a new header being actually created.
2023-01-21 14:34:43 <KipIngram   > And means storing that target in some other way - not just scraping it from the dictionary.
2023-01-21 14:35:03 <KipIngram   > See, for this processor work I'm committing the notion to hardware.
2023-01-21 14:35:31 <KipIngram   > Whenever a call is made, that extra cell will get pushed to the return stack, and :. will overwrite it.
2023-01-21 14:36:21 <KipIngram   > No time penalty, because I can make the return stack wider and handle both pieces at the same time.
2023-01-21 14:38:12 <KipIngram   > I originally thought of using a separate, but it's just a lot cleaner to integrate it with the return stack; that way the "levels" get kept up with properly.
2023-01-21 14:39:56 <KipIngram   > You could think of :. as "altering the definition" dynamically; it just effectively discards the first part which you don't want to execute anymore.
2023-01-21 14:40:40 <KipIngram   > I think of it "logically" as a new word name.  Exactly as though I'd done : foo ... : bar ... ;
2023-01-21 14:40:57 <KipIngram   > Except it just doesn't reeive a name and can only be used for "me" purposes.
2023-01-21 14:41:44 <KipIngram   > I guess in a traditional Forth system that would be
2023-01-21 14:41:50 <KipIngram   > : foo ... [
2023-01-21 14:41:54 <KipIngram   > : bar ... ;
2023-01-21 14:42:57 <KipIngram   > The main reason I wanted to move my headers away from my bodies in the first place was to allow that sort of construct.
2023-01-21 14:43:17 <KipIngram   > And I guess because Chuck talked about it being beneficial at some  point.
2023-01-21 14:43:44 <KipIngram   > It was reading about ColorForth that first twigged me to the notion.
2023-01-21 14:44:35 <KipIngram   > But I carried the CFA and PFA pointers away with the headers, which means I didn't REALLY get my headers separated from the "workings" of the system.
2023-01-21 14:45:24 <KipIngram   > But they had to move, because otherwise foo would try to execute bar's CFA.
2023-01-21 14:47:35 <veltas      > I'm unconvinced that your system is optimal, or pure, but it's your system
2023-01-21 14:48:17 <KipIngram   > I don't know that I'm claiming it's either.
2023-01-21 14:48:30 <KipIngram   > It's just something I feel like trying out.
2023-01-21 14:49:05 <KipIngram   > "Optimal" is a hard word to pin down.  Optimal how?  To whom?  Etc.
2023-01-21 14:49:14 <KipIngram   > It's not the "fastest."
2023-01-21 14:49:58 <KipIngram   > It does involve an extra instruction in docol, and an extra primitive call whenever I want to move the loopback forward.  Offsets would need neither - it would all get handled at compile time.
2023-01-21 14:50:23 <KipIngram   > It makes the return stack twice as big.
2023-01-21 14:50:51 <KipIngram   > Ever call gets this cell, and runs that extra instruction, whether it does any looping or not.
2023-01-21 14:51:06 <KipIngram   > So yeah - it's certainly not perfect in every respect.
2023-01-21 14:51:38 <KipIngram   > But, it will simplify a few things I'm doing now.  A little.
2023-01-21 14:51:53 <KipIngram   > It works well in hardware.
2023-01-21 14:51:59 <KipIngram   > That's part of its appeal to me.
2023-01-21 14:52:57 <KipIngram   > You still get the double-size stack, and still have to execute an instruction to move the target, but you don't pay that extra docol cycle.
2023-01-21 14:53:48 <KipIngram   > I consider this vs. the traditional approach somewhat like six of one, half dozen of the other.  They'll both get the job done.  Both have advantages and disadvantages.
2023-01-21 14:54:06 <KipIngram   > The big thing from today's chat I'm excited over is moving the pointers out of the headers and into their own table.
2023-01-21 14:54:22 <KipIngram   > I really like the potential access that gives me to 16-bit xt's.
2023-01-21 14:54:49 <KipIngram   > That still puts a size limit on the system, but not NEARLY as tightly as a standard 16-bit design would.
2023-01-21 14:55:35 <KipIngram   > I can still spread my system out over a full 32-bit address range; I'm just limited to 64k words.
2023-01-21 14:58:10 <KipIngram   > When I write it I'll try to arrange it so that I can choose that to be 16 bit or 32 bit xt's.  "Just in case."  I don't expect a 64k word limit to ever be an issue for me, but it does include ALL words, including factored helper words.
2023-01-21 14:59:05 <KipIngram   > So it would be nice to have a dodge in my hip pocket.
2023-01-21 15:00:18 <thrig       > fastest draw west of the mississippi
2023-01-21 15:22:25 <KipIngram   > Oh good.  I managed to grep up some old notes that I'd pecked into a text file and then not saved in a way I could remember.
2023-01-21 15:23:04 <KipIngram   > It had my recent work on the quit loop.  This time I want to rigorously start with quit and work my way down until I have a running system; include initially only those things required to make it run.
2023-01-21 15:23:41 <KipIngram   > I want to do the most direct path I can to ability to LOAD and then do the rest of the system using it as the dev tool.
2023-01-21 15:42:14 <KipIngram   > Hey, I just realized I can postpone providing a definition for a word with no cost at all - not even a little.  I'd make the header point to the nop primitive.  Then later I could do something like
2023-01-21 15:42:55 <KipIngram   > here ] ...def... [ ' <word> pfa h!
2023-01-21 15:43:09 <KipIngram   > Or, I guess I should put ; rather than [
2023-01-21 15:43:36 <KipIngram   > Of course that could be given some sugar to make it prettier.
2023-01-21 15:44:16 <KipIngram   > Something like >: word  ...def... ;
2023-01-21 17:09:53 <enthddd|||  > is there a small common portable c forth implementation
2023-01-21 17:13:23 <enthddd|||  > pforth might work
2023-01-21 17:13:28 <enthddd|||  > i have a few strange requirements
2023-01-21 17:15:19 <enthddd|||  > no pforth is too big, lbforth next
2023-01-21 17:20:40 <veltas      > What are your requirements?
2023-01-21 17:20:46 <veltas      > enthddd|||:
2023-01-21 17:30:00 <thrig       > ... and this forth, said goldilocks, was just right ...
2023-01-21 17:33:34 <KipIngram   > :-)
2023-01-21 17:34:19 <thrig       > probably the one you write for yourself
2023-01-21 17:34:56 <KipIngram   > ^^
2023-01-21 17:35:24 <thrig       > of course if you screw up then you (probably) cannot blame any problems on the government or some corporation or etc
2023-01-21 17:36:11 <veltas      > Well if we know their requirements maybe there are some suggestions
2023-01-21 18:28:43 <enthddd|||  > The requirements are actually not that specific and it isn't that important since it's just a for-fun implementation. It is for a calculator watch (sensor-watch.net). The requirements: memory is scare so it needs to realloc instead of creating giant buffers. it needs to pass control flow back to a caller after some N operations (even if it is in the middle of a dictionary traversal). i am in the
2023-01-21 18:28:49 <enthddd|||  > process of writing one myself but figure it probably takes someone a lot smarter than me to write a good Forth
2023-01-21 18:28:59 <enthddd|||  > oops sensorwatch.net
2023-01-21 19:13:02 <KipIngram   > If the Forth jumps to NEXT at the end of each primitive, rather than having it inline at the end of each one, then you could put a counter there and when it counted down you could take your break to go back to the caller then.
2023-01-21 19:13:17 <KipIngram   > But you have to be able to pick up there when you come back.
2023-01-21 19:13:43 <KipIngram   > I've got something like that in mine - every million trips through NEXT it detours and does some side work.
2023-01-21 19:14:18 <KipIngram   > The cost is a DEC register instruction and an un-taken conditional jump on passes through when you don't detour.
2023-01-21 20:17:25 <KipIngram   > Oh dear.
2023-01-21 20:17:39 <KipIngram   > My daughter is complaining about her Windows computer being sluggish.
2023-01-21 20:17:53 <thrig       > it's windows. that's what it does
2023-01-21 20:17:58 <KipIngram   > Why am I entirely unsurprised by this?
2023-01-21 20:18:09 <KipIngram   > ^^ exactly
2023-01-21 20:19:25 <thrig       > if not that, then it's throwing up a pop-up or doing some other damn fool thing
2023-01-21 20:19:48 <KipIngram   > Yeah.  I've avoided  Windows like the plague for years and years.
2023-01-21 20:27:59 <KipIngram   > But she's "uninformed."  She's getting uptight because she has "so many processes" running.  I'm trying to explain to her that a process can be "on the list" without necessarily placing much burden on her resources.
2023-01-21 20:28:17 <KipIngram   > That it depends on what the process is doing.
2023-01-21 20:29:26 <thrig       > windows apps? pegging multiple cpu cores whilst idling
2023-01-21 21:17:16 <KipIngram   > Guy I used to chat with who claimed to be "in the know" from his work swore that hardware companies (one of whom he worked for) actively lobbied Microsoft to consume as much CPU horsepower as possible, so they could justify peddling their faster computers to people.
2023-01-21 21:19:58 <KipIngram   > If that's true, then it's not a very big leap from there to figuring their "periodic updates" probably deliberately tear down your computer's performance.
2023-01-21 21:20:19 <KipIngram   > As soon as you've paid them for it, they don't want you to be happy with it.
2023-01-21 21:20:33 <KipIngram   > They want you longing for the next one.
2023-01-21 21:29:28 <MrMobius    > sounds too much like apple
2023-01-21 21:37:46 <thrig       > or from the bug and security reports Microsoft has no idea which way the bull is going to kick next and is hanging on for dear life
2023-01-21 21:51:15 <KipIngram   > Oh, they'll just wait to see what seems to be winning the popularity contest and then go buy a company that has that.
2023-01-21 21:51:25 <KipIngram   > That's how most big outfits operate.
2023-01-21 21:57:36 <KipIngram   > MrMobius: I think the difference there is that Microsoft just wants you money - Apple wants you to have a religious devotion to them.
2023-01-21 21:57:43 <KipIngram   > Along with wanting your money.
2023-01-21 22:33:09 <bjorkintosh > there's no religion without a small financial sacrifice.
2023-01-21 22:33:25 <bjorkintosh > s/religion/organized religion/
2023-01-21 22:37:26 <KipIngram   > Hey, in nasm, we work with these "sections."  Each is separate from the others, and you can specify which section to add to when you add new stuff.
2023-01-21 22:37:31 <KipIngram   > How many of those can I have?
2023-01-21 22:38:16 <KipIngram   > Can you specify in any way where your sections should be situated with respect to one another?
2023-01-21 22:39:12 <thrig       > uh that probably gets into ELFlandia
2023-01-21 22:43:27 <KipIngram   > So, do I have to use elf?  What would happen if I used -f bin in my nasm output, was careful about what I did, and then wrote a program that loaded that file into a RAM buffer and jumped to it?
2023-01-21 22:43:38 <KipIngram   > Feels like that ought to work.
2023-01-21 22:43:48 <KipIngram   > If it was relocatable code.
2023-01-21 22:44:14 <thrig       > linux lets you get away with all sorts of crap
2023-01-21 22:44:15 <KipIngram   > My code tends to be relocatable, because MacOS required it.
2023-01-21 22:44:27 <thrig       > oh macos. that will be MachOsomething
2023-01-21 22:44:36 <KipIngram   > I don't use it anymore.
2023-01-21 22:44:40 <KipIngram   > It's just where I started.
2023-01-21 22:45:06 <KipIngram   > I have a register that points to the base of my image, and all of my in-RAM addresses are really offsets from that register.
2023-01-21 22:45:28 <KipIngram   > So I can put it anywhere, so long as I adjust the register.
2023-01-21 22:45:43 <KipIngram   > In fact, first thing I do when my system starts up is copy the memory image into a new place and transfer control to it.
2023-01-21 22:46:04 <KipIngram   > I did that, and left the original image read-only, so that I could implement a real COLD.
2023-01-21 22:46:11 <KipIngram   > COLD just re-copies the load image.
2023-01-21 22:46:50 <KipIngram   > I may try -f bin this time, though.
2023-01-21 22:47:04 <thrig       > bin probably needs a minimal ELF header
2023-01-21 22:47:22 <KipIngram   > Yeah, or a separate ELF that loads it.
2023-01-21 22:47:30 <KipIngram   > Eventually such an image will be in a blocks.dat file.
2023-01-21 22:47:48 <thrig       > https://thrig.me/tmp/ret64.asm
2023-01-21 22:47:55 <KipIngram   > I'll have a little program that I can give a block range to, and it will open the blocks.dat, load that range, and jump to it.
2023-01-21 22:48:21 <KipIngram   > I'm sure I could bundle it with an ELF header too, if I putzed around with it some.
2023-01-21 22:49:35 <KipIngram   > But since I eventually want it in blocks.dat, I probably won't bother with that.
2023-01-21 22:49:56 <KipIngram   > Eventually I want to build it with my Forth itself; that's why it'll be in blocks.dat.
2023-01-21 23:53:24 <enthddd|||  > KipIngram: that's exactly what i am planning to do thanks