2023-05-12 01:36:18 <vms14       > crc look
2023-05-12 01:36:20 <vms14       > https://termbin.com/bs0o
2023-05-12 01:36:27 <vms14       > this is my dirty html generator
2023-05-12 01:36:35 <vms14       > I'm trying to add some microdata
2023-05-12 01:36:52 <vms14       > https://search.google.com/test/rich-results/result/r%2Farticles?id=Y63G4yFxqeYNMYMT6AtVPA
2023-05-12 01:37:44 <vms14       > https://vms.neocities.org/article the html itself
2023-05-12 01:37:59 <vms14       > the prop and type are microdata for the search engines
2023-05-12 01:39:41 <vms14       > I like this way more than the "forth" way, which is kind of a reverse way
2023-05-12 01:40:08 <vms14       > for forth makes more sense to "open" a tag, then add content to it, finally close that tag
2023-05-12 01:40:26 <vms14       > I just use lists and recursion instead :D
2023-05-12 02:04:04 <vms14       > https://search.google.com/test/rich-results/result/r%2Farticles?id=wkgu0Ck_TXog6na9lw7_Ow
2023-05-12 02:04:23 <vms14       > a bit hard to add all the microdata, but if I can automate it's cool
2023-05-12 02:04:37 <vms14       > https://termbin.com/hmjc
2023-05-12 03:27:56 <veltas      > > I just use lists and recursion instead
2023-05-12 03:28:07 <veltas      > So you open and close lists, instead of opening and closing tags
2023-05-12 07:42:18 <KipIngram   > vms14: I think for some aspects of meta-compilation it will be sufficient to have the word TARGET save the host's "next dictionary pointer" and reset it to the right value in the image beng built.  Then assembly language words will run as usual, putting there output into the new image.  Note that in this case you'd be RUNNING words from the host system, but re-directing their output to the target image.
2023-05-12 07:46:40 <KipIngram   > It's delicate, though.  Note that if you define a word using assembly words that generate machine code, you could get by finding those words in the host dictionary, if you're compiling for the same platform.  But for a : definition, you want to look the component words up in the target dictionary.  In both cases of course you want to create the header in the target system.  Generally speaking, any "immediate"
2023-05-12 07:46:42 <KipIngram   > word you encounter needs to be able to run now, which implies it's accessible for execution right now.
2023-05-12 07:48:11 <KipIngram   > I'll probably handle this by defining a host vocabulary that contains such immediate words, and search it before I search the target dictionary.
2023-05-12 07:49:16 <KipIngram   > And eventually you will need to compile target versions of those immediate words too, and yet you still may want to "use" those words for further compilation.  But that ought to be ok if I'm searching in the order I just described.
2023-05-12 08:01:20 <KipIngram   > You could put your target CREATE in that same "first search" directory - that's also a word you want to run on the host but deliver output to the target with.
2023-05-12 08:03:45 <KipIngram   > So basically think of a vocabularly META.  During meta-compilation you search META first, and any word found there gets executed, and afterward you search the target dictonary, and anything found there gets compiled (to the target).
2023-05-12 08:04:21 <KipIngram   > Of course when you *compile* the words in META, you're just doing normal host operations, so all your host system is available for that.
2023-05-12 08:11:15 <therepl_    > test
2023-05-12 08:13:19 <KipIngram   > A+
2023-05-12 08:13:59 <KipIngram   > Morning, therepl_
2023-05-12 09:02:36 <vms14       > the language does not stop changing, I can't get into a "stable" state yet
2023-05-12 09:03:53 <vms14       > it's the 3rd time I rewrite this and I'm going to rewrite it again
2023-05-12 09:04:20 <vms14       > I need to start making modules, so I can save some code
2023-05-12 09:06:09 <vms14       > I want to try to make the packages more like an environment
2023-05-12 09:07:49 <vms14       > and still need to think about some kind of error system
2023-05-12 09:19:42 <KipIngram   > Well, that's exactly what's happened to me over the years.  If you got a stable state the first shot, that would mean you'd benn "perfect," and we're not.
2023-05-12 09:19:57 <KipIngram   > You learn things by doing these iterations, so it keeps getting better.
2023-05-12 09:21:06 <KipIngram   > I'm excited about my upcoming iteration - this time I'm writing it IN FORTH, and that's a first for me.
2023-05-12 09:21:59 <KipIngram   > I have to implement vocabulary support in the host system, though.  My FIND already accounts for searching a list of vocabularies, but I don't have the words yet for creating new vocabularies, setting the search order, and so on.
2023-05-12 09:22:42 <KipIngram   > But now I've got this editor where I can LOAD it, and I used it yesterday to make some notes on this upcoming work.
2023-05-12 09:26:25 <vms14       > KipIngram: so you already have the metacompiler :0
2023-05-12 09:26:42 <vms14       > thats cool
2023-05-12 09:26:43 <KipIngram   > No, not at all.  I'll have to write it.
2023-05-12 09:26:46 <vms14       > oh
2023-05-12 09:27:04 <KipIngram   > But the first step is to write the stuff in that META vocabularly, so I need to be able to create that vocabulary.  :-)
2023-05-12 09:27:19 <vms14       > I want to get a way to transpile things
2023-05-12 09:27:35 <vms14       > I'd like it to not matter what language I use for the implementation
2023-05-12 09:27:59 <KipIngram   > This has been a long time coming for me - it's been on my "list" for years and years.
2023-05-12 09:29:22 <KipIngram   > BTW - this little editor is 630 bytes of source, but it compiles to 936 bytes of dictionary space.  So my 32-bit cells for xt's are having an effect there.  This new one will use 16-bit xt's, so the same code would go down to close to half the size.
2023-05-12 09:29:57 <KipIngram   > Well, the actually definitions would go to half the size.
2023-05-12 09:30:03 <KipIngram   > Headers won't really change.
2023-05-12 09:30:11 <vms14       > it's weird but I think what I want would be easier to achieve by using assembly xd
2023-05-12 09:30:24 <KipIngram   > I don't find that weird at all.
2023-05-12 09:30:24 <vms14       > I thought about using llvm's assembly
2023-05-12 09:30:33 <vms14       > I'd expect it to be portable
2023-05-12 09:31:32 <vms14       > KipIngram: what if the assembler instead of producing machine code, generates code in another language?
2023-05-12 09:32:10 <KipIngram   > Um, well, you certainly could "do" that.  I'm not sure I'd call it an assembler anymore.
2023-05-12 09:32:23 <vms14       > yeah xD it would be a transpiler
2023-05-12 09:32:32 <vms14       > but in a "lower level"
2023-05-12 09:32:37 <KipIngram   > What you'd be doing is implementing "instructions" on some vm in some high level language.
2023-05-12 09:33:03 <KipIngram   > You'd continue to be constrained by any limitations of that target language.
2023-05-12 09:33:10 <vms14       > I think it could help abstracting the transpiler a bit further
2023-05-12 09:33:17 <KipIngram   > And to get performance compatible with that target language.
2023-05-12 09:33:32 <vms14       > and some sort of compiler would write that fake assembly
2023-05-12 09:33:58 <vms14       > but this fake assembly could be a general way to get code in different languages
2023-05-12 09:34:21 <vms14       > meh, no idea I just need to think better about all this stuff
2023-05-12 09:39:16 <vms14       > my "ultimate" goal with the language is to have it transpiling code
2023-05-12 09:39:41 <drakonis    > its called intermediary representation
2023-05-12 09:40:24 <vms14       > yeah it's mainly that
2023-05-12 09:40:29 <vms14       > it helps decoupling a bit
2023-05-12 09:41:07 <vms14       > still it's just an idea, sounds like it could work somehow, but meh
2023-05-12 09:41:35 <drakonis    > it does indeed work
2023-05-12 09:42:05 <KipIngram   > I guess I'm not 100% sure how the size tradeoff will go on this.  On the one hand, I'm going to be compiling 16-bit xt's instead of 32-bit ones.
2023-05-12 09:42:23 <vms14       > KipIngram: why are you so worried about space?
2023-05-12 09:42:30 <vms14       > it's just you got used to?
2023-05-12 09:42:37 <KipIngram   > But on the other hand, each words's CFA and PFA pointers are likely to be 64 bits instead of 32 bit, so that will add 64 bits back in for each word.
2023-05-12 09:42:43 <drakonis    > have an IR target that's optimized for that
2023-05-12 09:42:44 <vms14       > I assume it kind of hurts when you see you're wasting space
2023-05-12 09:42:48 <KipIngram   > so it will depend on how fat my definitions are, and I tend to write short ones.
2023-05-12 09:43:10 <vms14       > but at the end is all about being efficient/correct
2023-05-12 09:43:22 <drakonis    > the major trade off is how much control you're going to give up for the ability to have an IR
2023-05-12 09:43:46 <vms14       > drakonis: can you elaborate?
2023-05-12 09:44:28 <KipIngram   > It's just a point of pride mostly, vms14.  A "metric" I carry around in my head is that a "full Forth system" can come in around 8kB.  But that's for a fully 16-bit design.  It's just always annoyed me a little for mine to be up around 17kB/18kB (primarily because I have a lot of 32-bit things rather than 16-bit things).
2023-05-12 09:44:33 <KipIngram   > It's still about right - it's about double.
2023-05-12 09:44:42 <KipIngram   > I was just hoping to trim that down some on this pass.
2023-05-12 09:45:07 <KipIngram   > I could use 32-bit CFA and PFA pointers if I wanted to, but it would change the NEXT code and I don't think it would be quite as fast.
2023-05-12 09:45:22 <KipIngram   > But it would still be pretty fast.  I just have to decide what's important to me.
2023-05-12 09:45:49 <drakonis    > basically, it adds a layer that separates your code from assembly, so it maps to the new layer instead of direct assembly
2023-05-12 09:46:12 <drakonis    > unless you have the means to bypass this extra step and write code that outputs assembly for the desired target
2023-05-12 09:47:01 <drakonis    > you'll incur some sort of penalty due to the generated assembly not being exactly what you would need when directly writing it
2023-05-12 09:47:14 <drakonis    > something something towering piles of abstractions
2023-05-12 09:47:30 <drakonis    > its not inherently bad or undesirable to have IR since it gives you portability
2023-05-12 09:48:02 <drakonis    > something like forth would definitely benefit from having it and an escape hatch at the same time
2023-05-12 09:48:14 <vms14       > hmm
2023-05-12 09:48:17 <KipIngram   > vms14: So, I have no "good" rational reason for being concerned about size.  It's just something that's of interest to me, just as performance is.  I like small and I like fast.  :-)
2023-05-12 09:48:58 <KipIngram   > But I know full well I have gobs more RAM that I'll ever need, and I also know full well that the right way to get peak performance is to profile and optimize the important bits with assembly.  So in the end neither of them "really matters."
2023-05-12 09:49:14 <vms14       > KipIngram: I think it's fine btw, once you're the one implementing everything, it's up to you, so it makes sense if you want to focus on size, its also likely to be the more correct way
2023-05-12 09:49:26 <vms14       > and the first rule of forth is simplicity after all
2023-05-12 09:49:54 <vms14       > about the transpiling stuff, I need to invest some time
2023-05-12 09:49:59 <drakonis    > i find that this isnt actually a bad idea
2023-05-12 09:50:39 <drakonis    > fun fact: my dad bought carolina reaper pepper sauce for my uncle
2023-05-12 09:50:51 <drakonis    > my uncle said he wanted something spicy, so my dad went and bought the spiciest sauce
2023-05-12 09:51:30 <KipIngram   > So let's say I wind up with 300 words.  Say 100 primitives and 200 definitions.  Just a guess.  Built-in primitives won't have a PFA pointer, so that's 400 extra bytes for those, above what I have now, if I go with "fastest NEXT," and for the definitions it's 1600 extra bytes.  So it's a 2kB trade-off in my final design.
2023-05-12 09:51:35 <KipIngram   > -ish
2023-05-12 09:52:08 <drakonis    > why not a layered forth design?
2023-05-12 09:52:33 <drakonis    > oops i sent the spicy sauce messages to the wrong channel
2023-05-12 09:52:38 <thrig       > Cambrian, Devonian, Archean,
2023-05-12 09:53:04 <KipIngram   > Spicy sauce is always interesting.
2023-05-12 09:53:39 <drakonis    > a spicy take.
2023-05-12 09:54:06 <drakonis    > this conversation is very inspiring.
2023-05-12 09:54:57 <drakonis    > using forth as an general assembler toolkit would be a fun thing
2023-05-12 09:56:44 <vms14       > drakonis: I always wondered about that
2023-05-12 09:57:03 <vms14       > if colon words write assembly code, they can be easily chained
2023-05-12 09:57:32 <vms14       > you could even use the normal assembly syntax by reading the next word
2023-05-12 09:58:08 <vms14       > add %eax 24
2023-05-12 09:58:48 <vms14       > : add42 add %eax 24 add %eax 24 ;
2023-05-12 09:58:53 <KipIngram   > But why would you do that when an rpn style is easier?
2023-05-12 09:59:08 <vms14       > I don't think it actually matters too much
2023-05-12 09:59:25 <vms14       > but yeah a rpn is just less hassle
2023-05-12 09:59:31 <vms14       > %eax 24 add
2023-05-12 09:59:39 <vms14       > or  24 %eax add
2023-05-12 09:59:59 <vms14       > the thing is then %eax needs to be a word
2023-05-12 10:00:13 <vms14       > which could be even better
2023-05-12 10:00:31 <vms14       > but my interest is how can this scale by using colon words
2023-05-12 10:01:46 <drakonis    > KipIngram: it is incompatible with how people normally write assembly, if they do that these days anyways
2023-05-12 10:02:00 <KipIngram   > Yes, you should have words corresponding to your registers.
2023-05-12 10:02:08 <KipIngram   > They'll load some "magic number" onto the stack.
2023-05-12 10:02:09 <Zarutian_iPad> still targetting legacy x86?
2023-05-12 10:02:31 <drakonis    > x86-64 it is
2023-05-12 10:02:42 <vms14       > also it kind of makes portability a bit easier
2023-05-12 10:02:44 <KipIngram   > I would go with "rax 24 add," myself.
2023-05-12 10:03:02 <vms14       > for example say in my system %eax is used for different stuff than in linux
2023-05-12 10:03:07 <KipIngram   > But rax 24 vs. 24 rax is really a matter of taste.
2023-05-12 10:03:27 <vms14       > so you should only to specify what registers are for, then use the task-related register
2023-05-12 10:03:32 <KipIngram   > The important thing is that the add comes last, and can use that magic number to figure out what exactly to do.
2023-05-12 10:04:03 <KipIngram   > If you found it easier, you could make rax a : definition and have it load a number and set some modes or something.
2023-05-12 10:04:27 <vms14       > instead of directly using %eax you would give some name related to what is %eax for
2023-05-12 10:04:29 <KipIngram   > In fact, I guess you should do that.
2023-05-12 10:04:39 <vms14       > for another machine instead of %eax would be another register
2023-05-12 10:04:47 <KipIngram   > Because otherwise how would you differentiate between "rax 24 add" and "rax rbx add"?
2023-05-12 10:05:22 <vms14       > you mean if rax and rbx returned values?
2023-05-12 10:05:27 <KipIngram   > rax would recognize that it's first (because your last instruction cleared all the state), and rbx would recognize that some other register word ran first, so they know which operatnd slot they're in.
2023-05-12 10:05:34 <vms14       > you could return some kind of string or a flag
2023-05-12 10:05:48 <KipIngram   > I think they would return values and also set some kind of mode bits.
2023-05-12 10:06:04 <vms14       > I'd just return a string
2023-05-12 10:06:24 <vms14       > : eax '%eax ;
2023-05-12 10:06:26 <KipIngram   > Well, I was assuming add would actually generate the correct machine code.
2023-05-12 10:06:43 <vms14       > there's a lot of ways to do it
2023-05-12 10:06:49 <KipIngram   > but of course I'm thinking in terms of a normal Forth that won't have string support.
2023-05-12 10:07:01 <KipIngram   > You may have other capabilities that simplify things.
2023-05-12 10:07:15 <vms14       > you can have a special flag for when a value is a register or not
2023-05-12 10:07:23 <vms14       > even two flags
2023-05-12 10:07:31 <KipIngram   > Right - register, immediate, RAM address, etc.
2023-05-12 10:07:47 <vms14       > actually the process can be as slow as you want, it will generate code
2023-05-12 10:07:47 <KipIngram   > It's a flexible situation - you could tackle in in a lot of ways.
2023-05-12 10:07:58 <KipIngram   > You just pick one and stick to it well.
2023-05-12 10:23:32 <KipIngram   > See, I will be writing such assembly words in this META vocabulary - they'll run on the host system but will generate output into the target image.
2023-05-12 10:30:05 <drakonis    > that's the thing, yes.
2023-05-12 10:31:22 <drakonis    > exactly the intent
2023-05-12 10:32:15 <crc         > vms14: using type values on the stack is what we do in rasc-x86
2023-05-12 10:35:01 <drakonis    > crc: i oughta ask, since you wrote a forth in assembly, would you still recommend fasm or its follow-up, fasm-g?
2023-05-12 10:35:09 <drakonis    > at least for bootstrapping the forth
2023-05-12 10:41:52 <KipIngram   > drakonis: I've written one in nasm, and that went well in my opinion.
2023-05-12 10:41:59 <KipIngram   > I had no complaints about the tool.
2023-05-12 10:42:13 <KipIngram   > Though a couple of folks were griping about how it handles local labels a couple of days ago.
2023-05-12 10:42:21 <KipIngram   > I just never used that feature, so it didn't affect me.
2023-05-12 10:42:37 <KipIngram   > I'm pleased with its macro facility - I got macros together to handle all the dictionary construction details.
2023-05-12 10:45:28 <drakonis    > the least appealing thing about nasm from what i've read so far is that it is effectively locked to outputting only x86
2023-05-12 10:46:06 <drakonis    > which isnt something bad, because its the only ISA i own hardware for
2023-05-12 10:46:17 <drakonis    > other than my phone, which is arm
2023-05-12 10:46:26 <KipIngram   > Ah.  Well, I've also never tried to generate anything else.
2023-05-12 10:46:39 <KipIngram   > So that could be a problem if you had some other goal.
2023-05-12 10:46:42 <drakonis    > fasm is also limited to just x86, sadly.
2023-05-12 10:46:53 <drakonis    > fasm-g is not
2023-05-12 10:47:13 <KipIngram   > Well, I guess it's great to have that flexibility, but somehow when I think "assembler" I think "assembler for a platform."
2023-05-12 10:47:15 <drakonis    > someone output a pdf quine with it
2023-05-12 10:47:31 <drakonis    > its somewhat funny and impressive at the same time
2023-05-12 10:47:34 <KipIngram   > If you have one that handles multiple, it's almost like shoehorning multiple assemblers together.
2023-05-12 10:47:41 <KipIngram   > At least it feels like that to me.
2023-05-12 10:47:48 <KipIngram   > But I guess I see how some features might be portable.
2023-05-12 10:47:49 <drakonis    > i suppose that might be true
2023-05-12 10:47:58 <KipIngram   > But every instruction would be expected to change.
2023-05-12 10:48:09 <KipIngram   > So I guess macro format and so on could be held consistent.
2023-05-12 10:48:43 <drakonis    > an assembler whose assemblers are built with macros
2023-05-12 10:49:23 <KipIngram   > Yeah, I kind of used macros to write a "pseudo-Forth assembler."
2023-05-12 10:49:37 <KipIngram   > When I need to do a definition, it looks like this:
2023-05-12 10:49:44 <drakonis    > for reference, this is the one i'm talking about https://flatassembler.net/docs.php?article=fasmg_manual
2023-05-12 10:49:51 <crc         > drakonis: I don't use fasm any more; though I still think it's an excellent assembler
2023-05-12 10:49:54 <KipIngram   >         def "name" name
2023-05-12 10:50:15 <KipIngram   >         run <word>, <word>, ..., dosem
2023-05-12 10:50:35 <drakonis    > i'd suggest using a paste service for this
2023-05-12 10:50:36 <drakonis    > it works best
2023-05-12 10:50:38 <KipIngram   > And that handles everything - creates the header, properly linked, builds the definition.
2023-05-12 10:50:43 <KipIngram   > Oh, sorry.
2023-05-12 10:50:46 <drakonis    > don't worry
2023-05-12 10:50:49 <drakonis    > i thought it would be longer
2023-05-12 10:50:50 <crc         > I've not looked at fasmg
2023-05-12 10:50:54 <drakonis    > it offers a fasm compatible assembler as a package, which seems nice enough
2023-05-12 10:51:02 <KipIngram   > I was worried someone would say something in between those lines.  But I got lucky.  :-)
2023-05-12 10:51:05 <drakonis    > ha
2023-05-12 10:51:26 <KipIngram   > name doesn't have to exactly match the string in "name"
2023-05-12 10:51:35 <KipIngram   > I do match them when feasible, but sometimes it's not.
2023-05-12 10:51:46 <KipIngram   > And all those <word> items are previous name values.
2023-05-12 10:52:10 <drakonis    > i've been wrestling a bit with getting fasmg to work last week before it had to take a backseat for this week
2023-05-12 10:52:14 <KipIngram   > I think it's about as good as you could get an assembler to do for specifying Forth.
2023-05-12 10:53:04 <drakonis    > what i was intending to make use of fasm-g for was to create a layer for outputting forth in multiple ISAs
2023-05-12 10:53:17 <drakonis    > just macrology all the way down
2023-05-12 10:53:57 <drakonis    > bootstrap a forth and then proceed to work at everything that can be done directly through forth
2023-05-12 10:54:12 <drakonis    > i'm not sure if that's an ideal path buuut
2023-05-12 10:54:17 <drakonis    > first time doing assembly
2023-05-12 10:56:13 <drakonis    > it'd be effectively a means to create a good substrate for a portable forth bootstrap
2023-05-12 10:57:20 <drakonis    > i am thinking too ahead here
2023-05-12 10:58:51 <KipIngram   > Thinking ahead is always good, in my opinion.
2023-05-12 10:59:14 <drakonis    > its more of a long term goal
2023-05-12 10:59:37 <KipIngram   > I think a lot of my re-writing arose from not thinking further ahead.  Of course, the further ahead you try to think, the less likely you are to be right.  :-)
2023-05-12 11:01:32 <drakonis    > too much thinking naturally leads to never doing anything
2023-05-12 11:01:51 <drakonis    > and that's an outcome i would like to avoid
2023-05-12 11:11:26 <KipIngram   > Well, that's true.
2023-05-12 11:11:36 <KipIngram   > One can get carried away with it, and I probably do at times.
2023-05-12 11:11:47 <KipIngram   > But I do enjoy the thinking too, and it is all mostly about having fun.
2023-05-12 11:13:13 <drakonis    > my dayjob is quite dull as far as creative thinking goes
2023-05-12 11:14:02 <drakonis    > it's devops things
2023-05-12 11:17:16 <KipIngram   > Yes, me too.
2023-05-12 11:17:57 <KipIngram   > At the high point of my career I was in charge of some really nteresting development work.  These days I do performance testing on our solid state drive product.
2023-05-12 11:18:00 <drakonis    > i wish i was paid more
2023-05-12 11:18:08 <KipIngram   > Which is interesting as testing goes - more interesting that functional test.
2023-05-12 11:18:20 <KipIngram   > At least I have to understand what's going on inside the drive to write effective tests.
2023-05-12 11:18:29 <KipIngram   > But it's not "as gratifying" as actual development work.
2023-05-12 11:18:48 <KipIngram   > My main "creativity fix" has come from developing my own tools for doing this work.
2023-05-12 11:18:58 <KipIngram   > The work itself is kind of boring.
2023-05-12 11:19:42 <drakonis    > indeed
2023-05-12 11:20:28 <KipIngram   > The last few months have been fun, because a new drive generation landed last fall, and we discovered that my previously existing test stands, which used this cable-based arrangement to connect up to the drives, wouldn't work, for signal integrity reasons.
2023-05-12 11:20:53 <KipIngram   > So I shifted to an entirely different platform, and that meant "rigging up" a new system to drive it.
2023-05-12 11:20:57 <KipIngram   > so I've gotten to do that.
2023-05-12 11:21:05 <KipIngram   > It's working quite well.
2023-05-12 11:21:30 <KipIngram   > We liked it so well, in fact, that we got two more of those boxes to expand my capacity.
2023-05-12 11:22:12 <KipIngram   > But the new ones have a "secure boot" feature that the old one didn't have, and that is giving us all kinds of grief.  I've got some fairly high level people helping me try to figure out how to get the drives to actually mount up in the Linux /dev/nvme hierarchy.
2023-05-12 11:22:28 <KipIngram   > We can see 'em on the PCI bus, but the OS can't "discover" them as drives.
2023-05-12 11:22:54 <KipIngram   > We changed something on the first box to circumvent that problem, but the secure boot won't let us do that on these.
2023-05-12 11:23:17 <KipIngram   > We could get the desired change "signed," but the source for it is owned by our contract manufacturer, and they won't share.
2023-05-12 11:23:26 <KipIngram   > So corporate bullshit is blocking the obvious "easy" solution.
2023-05-12 11:23:39 <drakonis    > your job is significantly more interesting than mine
2023-05-12 11:23:52 <KipIngram   > Hah.  In the "Chinese curse" way.
2023-05-12 11:24:28 <KipIngram   > But, it's fairly low stress and it does pay the bills - I'm happy enough to ride it on across the finish line.
2023-05-12 11:24:36 <KipIngram   > which isn't THAT many years away now.
2023-05-12 11:25:26 <drakonis    > mine is just computer janitoring with a overbearing boss
2023-05-12 11:26:45 <KipIngram   > Youngest kid is graduating from high school this year, so a logical time to start really thinking about retirement will be when we get her done with college.
2023-05-12 11:27:19 <KipIngram   > Though I'm a little torn over it - I seriously may decide to just "slow down some."  Let them decide how long to keep me after thta.
2023-05-12 11:27:22 <KipIngram   > that
2023-05-12 11:27:43 <KipIngram   > Though, I've never been "asked to leave" a job, so I'm not really sure I want to "invite" that at the very end.
2023-05-12 11:27:58 <KipIngram   > But in some sense it would feel like just walking away from extra money.
2023-05-12 11:28:13 <KipIngram   > I guess it depends on whether I think I can "slow down" and still do a job that qualifies as "good."
2023-05-12 11:28:28 <KipIngram   > I don't want to "cheat" them - it's more just that my tradeoffs will be different then.
2023-05-12 11:29:00 <KipIngram   > If I can continue to work, but at the same time just stop feeling "any stress at all," then that might work out well.
2023-05-12 12:27:05 <crc         > KipIngram: "A "metric" I carry around in my head is that a "full Forth system" can come in around 8kB." <- how do you define a full forth system?
2023-05-12 12:28:20 <thrig       > HUNGRY returns false
2023-05-12 12:51:41 <KipIngram   > crc: Um, "vaguely."  What that would mean to me, in general, is a nominally complete word set with a block editor present.  Something that I could use to do reasonable Forth development.
2023-05-12 12:51:49 <KipIngram   > I realize of course, that systems can vary wildly.
2023-05-12 12:52:05 <KipIngram   > I wouldn't expect a ton of luxury features on an 8kB full system.
2023-05-12 12:53:28 <KipIngram   > For example, I probably wouldn't expect to achieve that while providing my entire matrix of conditional return primitives.
2023-05-12 12:54:05 <KipIngram   > Once I explode out < <= = != >= >, signed and unsigned, and a couple of other "options" I wind up with well over a hundred of those.
2023-05-12 12:55:18 <KipIngram   > I have versions that take a 0 default argument along with two-argument versions, I have versions that do single return, double return, and loopback, and I also have versions that optionally retain the deepest provided argument.  So it blows up pretty fast.
2023-05-12 12:55:32 <KipIngram   > And that definitely is something I consider a "luxury."
2023-05-12 12:56:28 <KipIngram   > On the other hand, I don't have IF ... THEN, BEGIN ... AGAIN, or any of that sort of stuff - I do it all with these conditional primitives.
2023-05-12 12:57:19 <KipIngram   > And I've worked with the approach enough to know that I highly prefer it - it just feels more natural and I get the sense that my code is overall more compact.
2023-05-12 12:58:22 <crc         > I've not seen many that are 8k or less, at least on non-embedded systems
2023-05-12 12:58:45 <KipIngram   > I just read it somewhere - I guess it could turn out to be pretty uncommon.
2023-05-12 12:59:13 <KipIngram   > In a desktop / notebook system there's really just no *need* to strain for that level of "small."
2023-05-12 13:00:02 <KipIngram   > But my 32-bit system have tended to be around half that.  Probably if I could wand-wave one of those into a 16 bit system I'd wind up around 10-11 kB.  Just a uess.
2023-05-12 13:00:04 <KipIngram   > guess
2023-05-12 13:00:38 <crc         > Just a sampling of a few random ones form my collection:
2023-05-12 13:00:43 <crc         > Pygmy   	18,669 x86 DOS
2023-05-12 13:00:43 <crc         > FIG86NEW	7,056  x86 DOS
2023-05-12 13:01:16 <KipIngram   > And I am adding a bit structurally to this next one that will make it a little larger.  I'm separating the CFA and PFA pointers from the headers, which requires a new "index" field in the headers - that will add two bytes per word that just wasn't present before.
2023-05-12 13:01:59 <KipIngram   > Ok, well, that  FIG version there meets the claim.  Wonder if it has an editor at that size?
2023-05-12 13:02:15 <KipIngram   > But there's a kB to spare - one could be added that would fit in that.
2023-05-12 13:02:15 <crc         > my konilo is 14,476 bytes (or 3,649 cells)
2023-05-12 13:02:29 <KipIngram   > That's 32 bit cells?
2023-05-12 13:02:34 <KipIngram   > That's pretty good.
2023-05-12 13:02:42 <KipIngram   > I assume the FIG item you listed is 16 bits.
2023-05-12 13:03:01 <KipIngram   > If so, and if yours is 32 bits, I'd regard those as "similar" in size.
2023-05-12 13:04:01 <crc         > The FIG is 16 bits; it does have a block editor according to the manual
2023-05-12 13:04:11 <crc         > my system is 32 bit cells
2023-05-12 13:05:05 <KipIngram   > The nice thing is that there really isn't any "failing" at this - I just would like to see how well I can do size-wise.
2023-05-12 13:05:47 <KipIngram   > I may try to code it so that I can use either 32 or 64 bit CFA and PFA table entries.  That doesn't seem like it ought to be painfully hard to do, if I have it in mind from the start.
2023-05-12 13:06:48 <KipIngram   > Really just will involve adding the base address of the code region to 32-bit table values, whereas 64-bit table values will be actual addresses.
2023-05-12 13:07:26 <KipIngram   > May be difficult to have a spare register for that base address, though.
2023-05-12 13:07:47 <KipIngram   > I could make it work without one, but it would be a performance hit.
2023-05-12 13:08:10 <KipIngram   > Maybe not as bad as I might think, though - that value would get cached almost certainly.
2023-05-12 13:10:59 <KipIngram   > What I will get for the price of carrying that extra two-byte index in headers will be the complete elimination of any runtime operations on the header zone.  I'd be able to decapitate this system if I wanted to, and I've not previously written one that would actually allow that.
2023-05-12 13:14:39 <crc         > Some versions of RetroForth used to keep headers for hidden words in a separate area, then removed them when the hidden portion was sealed.
2023-05-12 13:37:44 <KipIngram   > Yes, I'm going to do that again this time.
2023-05-12 13:38:12 <KipIngram   > I did that once before - temporary headers in dynamically allocated memory.  The most recent time, though, I didn't actually "get rid of them" - I just unlinked them from the list.
2023-05-12 13:38:32 <KipIngram   > I've gone back and forth a little on what level memory management should come in at.
2023-05-12 13:39:03 <KipIngram   > I'm now back to thinking it should just be there right from the start.
2023-05-12 13:39:22 <KipIngram   > And that it deserves some careful attention toward getting it done right.
2023-05-12 13:39:45 <KipIngram   > I'll probably write something along the lines of Lea's allocator.
2023-05-12 13:43:27 <crc         > IIRC, the last time I had an actual memory manager in RetroForth was in the 9.x releases, as part of the optional ANS compatibility extension
2023-05-12 13:45:35 <KipIngram   > Mine was version before last.
2023-05-12 13:48:32 <KipIngram   > My existing system is right at 22kB with the editor loaded.
2023-05-12 13:49:21 <KipIngram   > That's not counting stack space.
2023-05-12 13:57:43 <KipIngram   > Oh, it occurred to me that earlier when talking about META and execute vs. compile I failed to mention numbers.  If a word is neither in META nor in the target dictionary, then we test it to see if it's a number - if that passes then it's the usual deal, except if STATE is set we compile it to the taret image.
2023-05-12 13:58:23 <KipIngram   > Basically all execution has to be stuff in META, or STATE=0 number; all compilation hits the taret dictionary.
2023-05-12 13:59:00 <KipIngram   > I don't intend to really try to "trick" the existing compiler into doing this - I'm just going to write a target compiler.
2023-05-12 14:01:19 <thrig       > he's switched off his targetting compiler
2023-05-12 14:01:42 <KipIngram   > May the Forth be with him!
2023-05-12 14:21:05 <KipIngram   > Hmmm.
2023-05-12 14:21:38 <KipIngram   > My "forth" word, which is a vocabulary, has a pointer to the CFA of the last word defined, and then two more cells allocated after that.
2023-05-12 14:21:57 <KipIngram   > The first of those additional cells is intended to be a pointer to the next vocabularly in a search order.
2023-05-12 14:22:05 <KipIngram   > But offhand I don't really remember why that second one is there.
2023-05-12 14:22:10 <KipIngram   > I obviously had something in mind.
2023-05-12 14:22:59 <KipIngram   > Right now it just functions as a variable, returning the address of the first cell (the CFA pointer location).   But I guess I'll modify that to have it do the expected usual behavior.
2023-05-12 14:23:17 <KipIngram   > Maybe I intended to make it a doubly linked list.
2023-05-12 14:23:40 <KipIngram   > Because if I execute a vocabulary that's already in the search order, I'll want to unlink it from where it is and bring it to the top of the list.
2023-05-12 14:24:03 <KipIngram   > And that can be done "locally" if it's a double linked list - I won't have to scan down the list to find the one currently pointing at it.
2023-05-12 14:24:16 <KipIngram   > That feels right, and I can't think of any other reason for having two cells there.
2023-05-12 14:30:02 <KipIngram   > For saving an existing search path, I may make a place to save the list, or I may just push a 0 onto the stack followed by each vocabulary address, all the way down.  Then when I put it back I can just rebuild the list, popping and adding, until I come to the zero.
2023-05-12 14:30:27 <KipIngram   > Storing something "large" like that on the stack probably isn't the greatest practice.
2023-05-12 14:30:53 <KipIngram   > But it's not like I expect to have a list dozens of vocabularies long or anything like that.
2023-05-12 14:57:41 <KipIngram   > I may move the name pointer from before the link pointers to after - if I always have doubly linked list pointers first in whatever record they're connected with, I can use a standard set of words for all of them.
2023-05-12 16:37:43 <KipIngram   > Well, that was pretty easy to do.
2023-05-12 16:37:55 <KipIngram   > Actually worked on the first try.
2023-05-12 17:33:07 <KipIngram   > Hmmm.  I think I see a nice way to implement DOES> stuff.
2023-05-12 17:35:46 <KipIngram   > Instead of CREATE ... DOES> ... we have a new word - BUILDS> or something.  It serves the same purpose as CREATE, but doesn't set the CFA to dovar.  Instead it will set it something else.  This something else will create an extra PFA slot, and will save it's address on the stack.  Then we do create the header, and when we come to DOES> it will backpatch that extra slot with the location where the DOES> code
2023-05-12 17:35:48 <KipIngram   > starts.
2023-05-12 17:37:00 <KipIngram   > Then when the word is executed, it will use the standard PFA to load an address onto the stack, but it will follow the extra pfa link to the address of the DOES> code and it will transfer control there, saving IP the way a : def would.
2023-05-12 17:37:52 <KipIngram   > In my current system this would just mean allocating one extra pfa cell, immediately before the usual one.  So instead of PFA, CFA we'd have PFA, PFA, CFA.
2023-05-12 17:38:45 <KipIngram   > In the new table-based system I'll have to use two indices, which means it'll consume two entries of both tables.  That's unfortunate, but it's unavoidable, I think.  That third data item is absolutely required, and since I use the same index to access both tables, I can only use them in pairs.
2023-05-12 17:39:20 <KipIngram   > Except the initial built-in primitives - I can avoid actually spending RAM on those unnecessary PFA fields by playing a little game with where the PFA table pointer points.
2023-05-12 17:39:47 <KipIngram   > It will point somehwere down well below where the actual list of PFAs starts, so that the first table entry matches up with the first : definition.
2023-05-12 17:40:13 <KipIngram   > But once I make that first definition that has a CFA and a PFA, then I'm stuck allocating pairs forever after.
2023-05-12 17:40:51 <KipIngram   > Anyway, I'd use a different word, BUILDS> instead of CREATE so that BUILD> can allocate that extra slot.
2023-05-12 17:41:16 <KipIngram   > It'll just save HERE on the stack and nudge HERE forward four bytes.
2023-05-12 17:41:20 <KipIngram   > (in my current system).
2023-05-12 18:49:43 <lispmacs[work]> MOLE WHACK
2023-05-12 18:49:59 <lispmacs[work]> some free code