2022-12-20 00:27:20 <KipIngram   > Ok, that took all evening, but it's installed and the dev board is ordered.
2022-12-20 00:28:02 <KipIngram   > The first install attempt want to install in /tools/Xilinx, but the way my drive is partitioned there wasn't enough room.  I changed it to /home/kipingram/Tools/Xilinx, and the install went fine (and took a long time), but it wouldn't run.
2022-12-20 00:28:50 <KipIngram   > Then I noticed that there is a flatpak installable gadget that will let me install the same stuff, downloaded from Xilinx; I tried it that way and tried one version earlier, and this time it defaulted to a directory in my /home/kipingram area, with plenty of room.  And that seems to run fine.
2022-12-20 00:29:04 <KipIngram   > I created an empty project that calls out the FPGA part number on the dev board.
2022-12-20 00:33:23 <KipIngram   > Well, anyway, this isn't the low power gadget I really wanted to use, but at leats it will let me do a design and make sure it works.
2022-12-20 00:33:51 <KipIngram   > And get a feel for how big a part I might actually NEED for what I'm doing.
2022-12-20 01:38:55 <decay       > god that microloop concept has my brain thinkin some things.
2022-12-20 01:45:52 <KipIngram   > :-)
2022-12-20 01:45:59 <KipIngram   > Fun.
2022-12-20 01:46:15 <KipIngram   > Yeah - I've always been fond of the idea.  Just seems totally natural in a packed opcode situation.
2022-12-20 01:46:23 <KipIngram   > So, the cmForth source code is a fairly interestng read.
2022-12-20 01:46:33 <KipIngram   > It's in theat Ting book I linked yesterday.
2022-12-20 01:48:52 <KipIngram   > You know, another possibility started to glimmer at me earlier.
2022-12-20 01:49:04 <KipIngram   > Let's say I fetch a cell from instruction RAM.
2022-12-20 01:49:51 <KipIngram   > So there is a slot0 instruction that begins executing immediately.  But what if slot1 instruction does something completely unrelated to slot0 instruction?  In certain cases, when we could see that, it might be possible to execute them in parallel and then shift 10 bits instead of 5.
2022-12-20 01:50:24 <KipIngram   > I don't yet have any ideas for how to recognize such a situation.
2022-12-20 01:50:43 <KipIngram   > But all six opcodes are there in the word - in a nice neat place where they could be analyzed.
2022-12-20 03:39:00 <veltas      > KipIngram: I definitely think stuff like PICK is necessary
2022-12-20 03:39:51 <veltas      > Sometimes, frankly, the stack just gets in the way of doing something with a lot of parameters. There is a number of ways to make this more comfortable in forth, such as using structures and allocating those structures on the stack, or in PAD, in dictionary, etc
2022-12-20 03:40:07 <veltas      > But sometimes you really do just want the 4th item on stack etc
2022-12-20 03:47:37 <veltas      > Locals are another way to make this more comfortable, and probably the most maintainable, but most easy to abuse and most easy to miss the point of Forth
2022-12-20 05:01:08 <veltas      > After all, what's simpler?   : S  1000 *  MS ;    or    : S { t }  t 1000 *  MS ;
2022-12-20 06:02:46 <KipIngram   > Honestly, it just feels like that is the way it probably "ought" to turn out.  Just on the basis that there's actually not anything "perfect" in the world.
2022-12-20 06:05:22 <MrMobius    > KipIngram: I have thought about that kind of parallelism. You could almost treat each 32 bit word as a separate instruction that does 5 things potentially all in parallel or inserts some waits and does it in steps
2022-12-20 06:07:47 <KipIngram   > Yes, and you could just make that manually explicit; tasking hte programmer with recognizing that parallelism.
2022-12-20 06:08:09 <KipIngram   > The question then would be "what do you do with the slots when there is no opportunity for parallelism?"
2022-12-20 06:09:19 <KipIngram   > If I were trying to automate the recognition of opportunities, I might have each five bits to into a little table that produced a "resource vector," and if a field didn't share any bits with any of the prior fields it would be qualified to run "now."
2022-12-20 06:09:46 <KipIngram   > Not "resources," but rather "modified things" compared to "used things" in later instructions.
2022-12-20 06:09:55 <KipIngram   > You get the idea, I expect.
2022-12-20 06:26:23 <KipIngram   > Maybe consider "over +".  To get the result of that in one cycle would be easy with the hardware you have for doing them separately.
2022-12-20 06:26:47 <KipIngram   > You'd just not collapse from two items to one.  Just add NOS to TOS, without moving anything.
2022-12-20 06:27:06 <KipIngram   > So is there any way to "see to do that" in a straightforward way?
2022-12-20 06:27:56 <KipIngram   > Doing those in paralle would be better in every way than doing them sequentially.
2022-12-20 06:29:59 <KipIngram   > It would eliminate a RAM write, a RAM read, and a stack pointer adjustment.
2022-12-20 06:30:08 <KipIngram   > Actually two pointer adjustments.
2022-12-20 06:44:54 <MrMobius    > ya it would be a pain to always keep them in the same word if you are counting on over + being fast for example
2022-12-20 07:04:47 <KipIngram   > Yes, it would.  Anytime something like that "matters" then it brings things to think about.
2022-12-20 07:06:53 <MrMobius    > sounds like you're getting close to i860/Itanium territory
2022-12-20 07:07:01 <KipIngram   > Yesterday decay was mentioning the benefits of wider instruction words.
2022-12-20 07:07:44 <KipIngram   > You know, I'm really not familiar enough with the actual details of that history to be able to pin specific names on such things, but yeah, I know that Intel went down a slippery slope on things like parallelizing, out of order execution, and so on.
2022-12-20 07:07:59 <KipIngram   > One can invest an awful lot of logic in such things once begun on that path.
2022-12-20 07:08:22 <KipIngram   > When does it become smarter to not do that and have more cores?
2022-12-20 07:08:43 <MrMobius    > the idea of i860 as I understand it was that a lot of the work would be pushed off onto the compiler to arrange the VLIW stuff which did not go over  well
2022-12-20 07:08:44 <KipIngram   > Likely "it depends" on the problem you're trying to solve.
2022-12-20 07:08:59 <KipIngram   > Yeah.
2022-12-20 07:09:08 <KipIngram   > It was probably a good thing to investigate.
2022-12-20 07:09:37 <MrMobius    > I imagine I would be annoyed if performance kept fluctuating depending on one tiny change to the source
2022-12-20 07:09:37 <KipIngram   > But ultimately the payoff probably IS application dependent, and it's hard to know what the market is going to value.
2022-12-20 07:10:06 <KipIngram   > Yes, well, we have that situation today in things like false sharing around cache memory.
2022-12-20 07:10:21 <KipIngram   > Move one variable over a few bytes, and suddenly your performance is way up, or down.
2022-12-20 07:10:55 <MrMobius    > that's fine. at least you can reason about it and keep your solution once you  find it. the gains dont go away from making a change to one line 1,000 lines before it
2022-12-20 07:11:44 <KipIngram   > Yeah, and there are tools for investigating such things.
2022-12-20 07:12:19 <KipIngram   > It's easy to see the path to cache too - here I have this chip with block RAMs.  Fetching code from an external RAM might be slow, hence one gets tempted to try to stow things away locally for re-use.
2022-12-20 07:13:13 <KipIngram   > That idea in and of itself isn't a bad one - I imagine most of the logic cost that has come over the years has come from trying to make it a completely transparent, hidden process.
2022-12-20 07:13:38 <KipIngram   > I saw one processor a few years ago that let you address RAM via multiple parts of the address space, and which one you chose affected whether the content was cached or not.
2022-12-20 07:13:54 <MrMobius    > ya microcontrollers do that sometimes
2022-12-20 07:13:54 <KipIngram   > That seemed like a clever idea to me - let the programmer, who supposedly knows what's going on, help.
2022-12-20 07:15:41 <KipIngram   > I think that kind of "collaboration" sometimes works really well.  I bragged on Palm Graffiti the other day - I think one reason that it worked so well was that they did not try to just "recognize standard characters."  They had you learn a slightly modified set of characters, and they found a set that was a) easy to learn and intuitive, and b) very easy to recognize via the hardware.
2022-12-20 07:15:51 <KipIngram   > It was a damn clever concept.
2022-12-20 07:16:08 <KipIngram   > They found a "sweet spot."  But then they got sued and had to cripple it.
2022-12-20 07:16:52 <KipIngram   > And the combination of that cripping and their "cheapening" of the later products just spoiled the situation.
2022-12-20 07:17:14 <KipIngram   > Biggest cheapening was they they went from glass to plastic for the touch screen, and the plastic degraded over time.
2022-12-20 07:17:58 <KipIngram   > Graffiti went to one small region of the screen, and the way I used the thing I'd wear it out in a matter of months with those plastic screens.
2022-12-20 07:19:35 <KipIngram   > Part of the appeal of making a little pocket-size touch screen gadget for me is that maybe I could have again something that worked that really nice way.  I have very found memories of how effective it was for me.
2022-12-20 07:19:55 <KipIngram   > Of course these days I don't have nearly so much to keep track of as I did then.  :-)
2022-12-20 07:20:39 <KipIngram   > Also, back then there just weren't any of these big systems that they always try to make everyone use in a shared way.
2022-12-20 07:21:09 <KipIngram   > What good is a pocket personal organizer that works in some unique way, if you're also expected to keep everything in sight in JIRA or something like that?
2022-12-20 07:21:51 <KipIngram   > Where they get the idea that one tool is going to be a good fit for everyone I have no idea.
2022-12-20 07:22:41 <KipIngram   > On the one hand, they give us all this mandatory training on on "diversity."  Then they turn around and say "And you have to do your job exactly like this."
2022-12-20 07:26:39 <KipIngram   > Zarutian_iPad: Back to yesterday's discussion, I got fairly excited about the potential for that restructuring I described (using an outside event loop with events passed into code to handle them, rather than fetching keyboard I/O from inside EXPECT).  But even if it solves the problem, I think it doesn't end the discussion.
2022-12-20 07:27:27 <KipIngram   > What if I *insist* that EXPECT work in the traditional Forth standard way?  That happens not to be a requirement I face, and in fact the other approach dovetails nicely with my interest in SDL that came up the day before.
2022-12-20 07:28:04 <KipIngram   > But what if?  Say we want expect to work exactly like Forth has always had it work?  I am no closer to seeing how to avoid needing those items on the stack than I was before in that case.
2022-12-20 07:28:33 <KipIngram   > I spent quite a lot of time working on that - I feel like if there were an "obvious" way to avoid needing that info on the stack I'd have seen it.
2022-12-20 07:28:51 <Zarutian_iPad> the screen position should live in a USER variable
2022-12-20 07:29:54 <Zarutian_iPad> as it is part of the ?terminal stuff? rather than editing the string buffer stuff
2022-12-20 07:30:03 <KipIngram   > Ok, that's fair.  And makes sense in the context of an editor.  But if all you have is EXPECT, I'm not sure I see that - if EXPECT is the only place that value is every used, and it's not expected to persist across calls, then that seems painful - to introduce a global JUST to get an item off the stack.
2022-12-20 07:30:15 <KipIngram   > It feels to me like variables should be for values you need over a long period of time.
2022-12-20 07:30:37 <KipIngram   > I agree with you that in the big picture that's the case.
2022-12-20 07:30:56 <KipIngram   > But I could envision a "non fancy" system in which you never did anything other than call EXPECT.
2022-12-20 07:31:30 <Zarutian_iPad> and if you are storing utf8 then you can scan forward each byte to find the start of the codepoint
2022-12-20 07:31:43 <KipIngram   > I don't know that I've ever seen a discussion in any reference book about "screen position" being a user variable.
2022-12-20 07:32:20 <KipIngram   > Yeah, by the time I was done with that I'd given up trying to "move around in the middle" of my string and had gone to scanning over from the start on every keystroke.
2022-12-20 07:32:37 <KipIngram   > But this was already a problem before I added utf8 - utf8 just made it worse.
2022-12-20 07:32:40 <Zarutian_iPad> USER variable as in a global per user, if you have a multi user Forth
2022-12-20 07:32:50 <KipIngram   > Initially buffer col and screen col were the same.
2022-12-20 07:33:08 <veltas      > I think USER is also per-thread if you have threads
2022-12-20 07:33:14 <KipIngram   > Right right - I'm not disagreeing that in a lot of systems that would be a useful variable.
2022-12-20 07:33:23 <veltas      > There are USER variables and user dictionaries, two different things
2022-12-20 07:33:37 <KipIngram   > But I can picture a system in which it's not - where it's never touched at all except inside EXPECT.
2022-12-20 07:33:47 <Zarutian_iPad> and I think screen position should live there for the same reason that ?KEY and TX! vectors live there
2022-12-20 07:33:48 <veltas      > user dictionaries are per-user, USER variables are per thread (and per user, as each user terminal is in a different thread)
2022-12-20 07:34:20 <KipIngram   > Yes - let's set t hose complications aside.
2022-12-20 07:34:26 <KipIngram   > Let's look at the simplest possible case.
2022-12-20 07:34:29 <veltas      > Terminal stuff should be per-terminal, i.e. should be in user dictionary, not USER variables
2022-12-20 07:34:40 <KipIngram   > I call expect, get a string, and otherwise never deal with the keyboard at all.
2022-12-20 07:35:00 <KipIngram   > Now I'm putting that value in a variable ONLY to not have it on the stack.
2022-12-20 07:36:21 <KipIngram   > veltas: I think I agree with that.
2022-12-20 07:36:33 <KipIngram   > never mind think - I do agree with that.
2022-12-20 07:37:02 <KipIngram   > That actually feels like a better justification for having it in a variable anyway.
2022-12-20 07:37:14 <KipIngram   > Regard the terminal as a black box, so to speak.
2022-12-20 07:37:22 <KipIngram   > If you want to know where the cursor is, ask it.
2022-12-20 07:38:35 <KipIngram   > Maybe that is enough to get us there.  Even if we want UTF8, we can scan from the beginning anytime we need to get from cursor position to buffer position.
2022-12-20 07:39:47 <Zarutian_iPad> the neat thing with utf8 is you can scan backwards too
2022-12-20 07:39:54 <veltas      > Well what I mean is you only need an instance of terminal variables per-terminal
2022-12-20 07:40:10 <veltas      > Whether you store them in cells or actually request it from the terminal is up to you
2022-12-20 07:40:24 <veltas      > Requesting the terminal makes more sense to me as a firmware/driver engineer
2022-12-20 07:40:25 <KipIngram   > So that leaves us needing buffer address, buffer size on the stack all the time throughout.  So I can get at buffer address only when there is nothing else whatsoever on the stack.
2022-12-20 07:41:06 <KipIngram   > Yes, black boxing the terminal and asking it for cursor pos makes more sense to me too.  Why remember it outside?
2022-12-20 07:41:11 <veltas      > I've not kept track of why this needs to be on stack, I don't think should be on the stack
2022-12-20 07:41:14 <Zarutian_iPad> I might be balphemous here for suggesting incorporation of an object system (not oo though)
2022-12-20 07:41:29 <KipIngram   > Well, a terminal IS sort of an object.
2022-12-20 07:41:37 <veltas      > You always have structs, they're just always explicit
2022-12-20 07:41:42 <Zarutian_iPad> if you are going to do more and more complex stuff
2022-12-20 07:41:45 <veltas      > not* always
2022-12-20 07:41:52 <KipIngram   > Associating a variable with it doesn't feel as obtuse and just shoving a variable into the dictionary.
2022-12-20 07:41:57 <veltas      > Dictionary entries are basically structs....
2022-12-20 07:42:17 <veltas      > Structs are there, it's just a matter of whether you admit they exist or not
2022-12-20 07:42:42 <KipIngram   > So this MAY get the solution within reach - but it's borderline enough I'd have to scratch out some code to have a real opinion.
2022-12-20 07:43:14 <KipIngram   > Say I've got address and size on the stack.
2022-12-20 07:43:20 <veltas      > Obtuse is best in forth
2022-12-20 07:43:34 <veltas      > Forth is not actually meant to be difficult to understand, it's meant to be simple
2022-12-20 07:43:53 <KipIngram   > I can OVER to get addr on top, ask terminal for cursor pos, and scan that addr copy forward to get buffer addr.
2022-12-20 07:44:17 <Zarutian_iPad> it just violates unstated assumptions many folk have
2022-12-20 07:44:23 <KipIngram   > Then I can get a keystroke, or pull it back off of the return stack, or whatever, and modify the buffer.
2022-12-20 07:44:30 <veltas      > Zarutian_iPad: Like what?
2022-12-20 07:44:33 <KipIngram   > Send it to terminal to make the screen actually change.
2022-12-20 07:45:12 <KipIngram   > Ok, I'm willing to buy that treating the terminal like a msart subsystem probably gets us over the finish line.
2022-12-20 07:45:20 <KipIngram   > smart
2022-12-20 07:45:22 <Zarutian_iPad> veltas: Forth violates the assumptions that many folks have regarding stuff like syntax
2022-12-20 07:45:52 <KipIngram   > What's an example of such an assumption?
2022-12-20 07:46:55 <Zarutian_iPad> one is that algol68 stuff like expression 2 + 2 works that way
2022-12-20 07:47:02 <KipIngram   > so anyway, the problem arose from asking EXPECT to manage the terminal as well as the buffer, without having any resources with which to do so.
2022-12-20 07:47:17 <KipIngram   > Other than the stack.
2022-12-20 07:47:47 <KipIngram   > And I think that was the point you were trying to make yesterday, Zarutian_iPad.
2022-12-20 07:47:51 <veltas      > Zarutian_iPad: Yeah but in my opinion Forth is inherently difficult to understand, even beyond cultural norms etc. But I think the art of forth is figuring out what you can do simply and understandably despite constraints
2022-12-20 07:48:15 <KipIngram   > See, that's not how I feel at all.  It has always felt incredibly natural and straightforward to me.
2022-12-20 07:48:18 <veltas      > KipIngram and I have argued about this before
2022-12-20 07:48:21 <KipIngram   > About as straightforward as something can be.
2022-12-20 07:48:29 <KipIngram   > :-)
2022-12-20 07:48:33 <veltas      > Some of it is more straightforward, sometimes, but I don't agree in general
2022-12-20 07:48:47 <KipIngram   > I think it has a lot to do with me learning to program in the first place on an RPN calculator.
2022-12-20 07:49:09 <KipIngram   > My experience is likely a minority one.
2022-12-20 07:49:29 <veltas      > Well you can share "good forth code" that is maintainable etc and I can read that and maybe learn something
2022-12-20 07:49:38 <veltas      > Like do you have a public repo for your code?
2022-12-20 07:54:11 <KipIngram   > No, not really.  And I've not actually written an ENORMOUS amount of application code - most of my Forth is the Forth I wrote to implement features of my system.  Plus I've evolved this odd style that uses my conditional return control structures and so on - it's really not what most people's Forth would look like.
2022-12-20 07:54:21 <KipIngram   > It works intuitively for me, but YMMV.
2022-12-20 07:54:55 <KipIngram   > I have found that if I write something and then go back a year or two later and study it again, it's generally not hard for me to recall what I was doing.
2022-12-20 07:55:03 <KipIngram   > But I may just REMEMBER.
2022-12-20 07:55:17 <KipIngram   > Doesn't mean someone unfamiliar with my code would have a clue what was going on.
2022-12-20 07:57:31 <KipIngram   > I've always had it in mind I would put it in a repo at some point, but I've never felt it was "finished and ready," and it would annoy me if I published it and someone else grabbed it and "finished it."
2022-12-20 07:57:39 <KipIngram   > Wouldn't feel altogether mine anymore.
2022-12-20 07:58:12 <KipIngram   > On the other hand, someone taking something I regarded as done and modifying it - that wouldn't bug me nearly as much.
2022-12-20 07:58:46 <KipIngram   > I think a lot of people would object to the way I spread control structures up and down verticaly in the call chain.
2022-12-20 07:59:12 <Zarutian_iPad> KipIngram: ah, you like many look at public repos as something that is published and done
2022-12-20 07:59:15 <KipIngram   > I tend to write little "groups" of definitions that are tightly related to one another in that way.
2022-12-20 07:59:43 <KipIngram   > Well, I know that's not always the case - that in a lot of cases the very idea is to secure public collaboration.
2022-12-20 07:59:50 <Zarutian_iPad> me? I often treat my repos as like a pottery wheel, you are going to see mess in progress
2022-12-20 08:00:01 <KipIngram   > Yeah.
2022-12-20 08:00:19 <KipIngram   > I don't mean to be critical of that approach.
2022-12-20 08:03:11 <Zarutian_iPad> I think there is a factor called ‘artists shame/embarresment’ that playes into it
2022-12-20 08:03:29 <Zarutian_iPad> that is delaying public git repo commits
2022-12-20 08:04:01 <KipIngram   > I can see that, but I think it's slightly different from what I'm talking about.
2022-12-20 08:04:19 <KipIngram   > Although looking back I certainly feel some of that re: my older efforts.
2022-12-20 08:04:25 <KipIngram   > Especially the one I wrote in C.
2022-12-20 08:04:36 <KipIngram   > It worked fine - did everything I wanted it to the way I wanted it to.
2022-12-20 08:04:41 <KipIngram   > But my god it was ugly.
2022-12-20 08:04:47 <Zarutian_iPad> some repos I have come across are essays of the author thiniking through a problem
2022-12-20 08:04:59 <KipIngram   > Used C macros to specify the definitions, and... what mess.
2022-12-20 08:05:11 <KipIngram   > Eventually I could no longer maintain it, so I started over in nasm.
2022-12-20 08:05:26 <Zarutian_iPad> essays as in try and not as in a paper for school
2022-12-20 08:05:35 <KipIngram   > Right.
2022-12-20 08:07:27 <KipIngram   > So this SDL stuff; it's really just another example of "treating the terminal as an independent system," except it's treating "the environment" that way.  Just extending that same model to all of the "stuff" that the code needs to interact with.
2022-12-20 08:08:06 <KipIngram   > It's just that if EXPECT is the only word that really deals with that terminal stuff, you can hide the calls to that stuff inside EXPECT.
2022-12-20 08:08:16 <KipIngram   > Whereas a general SDL interface needs to be more flexible.
2022-12-20 08:08:27 <KipIngram   > Because you've no idea what the user will "do next."
2022-12-20 08:08:45 <jackdaniel  > 
ACTION did not expect that

2022-12-20 08:24:08 <KipIngram   > So, six-input LUTs sure are nice compared to for.  In particularly, 6 > 5, so it's a simple matter to produce any signal I need with the opcode passed through one LUT.
2022-12-20 08:25:24 <KipIngram   > Having those extended opcodes, though, makes a second layer necessary.  But there are my "two layers of logic" between flip flop output and flip flop input.
2022-12-20 08:26:51 <KipIngram   > One layer decodes the primary five bits, and a second lut takes that signal in, an "extend" signal, and four bits from the secondary opcode values.
2022-12-20 08:27:03 <KipIngram   > So, two LUTs per control signal.
2022-12-20 08:28:30 <KipIngram   > And that would be without any intelligent encoding at all - if I'm clever with opcode assignment I can likely simplify it.
2022-12-20 08:28:56 <KipIngram   > Hopefuly I can arrange to just have opcode bits directly BE some of the control signals.
2022-12-20 08:29:06 <KipIngram   > Or only need one layer of processing.
2022-12-20 08:32:51 <MrMobius    > hmm, I dont get the comment about LUTs. what does it matter? you wont be touching the LUTs anyway since it will be written in HDL
2022-12-20 08:33:19 <KipIngram   > I don't think in terms of behavioral Verilog.
2022-12-20 08:33:34 <KipIngram   > I picture logic circuits - wires connecting up LUTs, registers, etc.
2022-12-20 08:33:41 <KipIngram   > The way I'd operate if I were drawing a schematic.
2022-12-20 08:33:52 <MrMobius    > thats fine. you can use VHDL or something. you still wont be working at the LUT level
2022-12-20 08:34:01 <MrMobius    > that isnt even the gate level
2022-12-20 08:34:06 <KipIngram   > Ultimately you are - those are your logic resources.
2022-12-20 08:34:27 <KipIngram   > You can't get a feel for how many resources a job takes unless you picture what the LUTs are doing.
2022-12-20 08:34:48 <KipIngram   > For example, one bit of a 4-1 mux takes one six input LUT.
2022-12-20 08:35:00 <KipIngram   > Four inputs, two controls, one output.  Perfect fit.
2022-12-20 08:35:03 <MrMobius    > I dont think anyone can really picture it to that accuracy in their head to be honest
2022-12-20 08:35:17 <KipIngram   > That's how I do it, though.
2022-12-20 08:35:19 <MrMobius    > more like start working on your design and watch it grow to see hwo close youre getting ot the limit
2022-12-20 08:35:26 <KipIngram   > Maybe I just picture small pieces of it at a time.
2022-12-20 08:35:39 <KipIngram   > I agree that in general you can't picture the entire thing all at once.
2022-12-20 08:36:10 <KipIngram   > No, just not how I do it.  I think about the low level for the core functionality first - to make sure that's an "excellent fit."
2022-12-20 08:37:08 <MrMobius    > right. thats what I mean. I dont think you will get an "excellent fit" that way. even if youre doing lower level HDL I doubt you cant reason about the individual LUT and make meaningful conclusions
2022-12-20 08:37:09 <KipIngram   > So at the moment I see eight registers in this thing.  TOS, NOS, SP, TOR, RP, IP, IW (holds the opcode sets), and then FP (my frame pointer).
2022-12-20 08:37:15 <KipIngram   > Am I neglecting something obvious?
2022-12-20 08:37:31 <KipIngram   > I feel that I can, enough to make it worth the effort.
2022-12-20 08:37:35 <KipIngram   > I've done so in the past.
2022-12-20 08:37:40 <MrMobius    > like it takes 16 LUTs to do it this way but only 17 the other way and that it actually matters either way at the end of the day when it comes to max speed you can run at or anything else
2022-12-20 08:37:51 <KipIngram   > When I'm done, I want to understand EXACTLY what's going on in there and how.
2022-12-20 08:38:10 <KipIngram   > Granted, before I'm done an auto place and route will have been done.
2022-12-20 08:38:20 <KipIngram   > So I won't "know" WHERE everything is, unless I look.
2022-12-20 08:38:32 <KipIngram   > But WHAT'S going on I want to understand.
2022-12-20 08:39:19 <KipIngram   > I mean, I just did it, for an example part of the design.
2022-12-20 08:39:38 <KipIngram   > I went from having the current primary and secondary opcode slots to a generic structure to produce any necessary control signal.
2022-12-20 08:39:58 <KipIngram   > I may improve on that with careful instruction encoding - what I described up there would work for any arbitrary encoding.
2022-12-20 08:40:23 <KipIngram   > Lets me use two 6-input LUTs to get any control signal for up to 47 instructions.
2022-12-20 08:40:42 <KipIngram   > If I wanted to go all the way to 63 I'd need three LUTs per signal.
2022-12-20 08:41:04 <KipIngram   > I can picture that much, at least, with complete clarity.
2022-12-20 08:41:43 <KipIngram   > So I see at least three levels you can come at a problem like this from.
2022-12-20 08:42:05 <KipIngram   > 1) You can be completely behavioral.  Just desribe the results you want and let the synthesizer to the rest.  Kind of like how the J1 is written.
2022-12-20 08:42:33 <KipIngram   > 2) You can think in terms of generic logic, like 4-1 mux, 8-1 mux, etc.; let the synthesizer decide how to LUTify that.
2022-12-20 08:42:48 <KipIngram   > 3) You can do what I'm doing here, and at least envision how LUTs will be deployed.
2022-12-20 08:42:58 <KipIngram   > Now, it might not deploy them that way.  I'd look upon that as a shortcoming.
2022-12-20 08:43:18 <KipIngram   > That would be like a compiler failing to produce the best possible assembly language.
2022-12-20 08:43:44 <KipIngram   > I think approach 3 is the best way to do the job.
2022-12-20 08:44:16 <KipIngram   > And I don't think approach 1 even qualifies as "hardware design."
2022-12-20 08:44:54 <KipIngram   > Approach 1 is trying to do a job you're not really competent to do - you're totally using the tool as a crutch.
2022-12-20 08:45:32 <KipIngram   > With approach 3, you have an EXPECTATION as to what your timing will be.  With approach 1 you have no idea whatsoever - you just build it and see if you're happy.
2022-12-20 08:46:05 <KipIngram   > And if you're not... well, I guess you wander around trying to see if you can find a change that will make it better.
2022-12-20 08:46:54 <KipIngram   > Basically to me approach 3 is designing with gates - in this case arbitrary six-input logic gates.
2022-12-20 08:47:49 <KipIngram   > Approach 2 is designing with less specific gates; gates and other devices that don't map exactly onto your true resources.
2022-12-20 08:48:15 <KipIngram   > Approach 1 is just talking about what you want.
2022-12-20 08:48:37 <KipIngram   > Or, another perspective:
2022-12-20 08:48:41 <KipIngram   > 1) Writing a specification
2022-12-20 08:48:50 <KipIngram   > 2) Writing in a high level language
2022-12-20 08:48:54 <KipIngram   > 3) Writing in assembler
2022-12-20 08:49:44 <KipIngram   > Anyway, did anyone catch me forgetting a necessary register?
2022-12-20 08:52:08 <KipIngram   > I may need some registers to hold RAM addresses - ones not visible to the programmer.
2022-12-20 08:52:24 <KipIngram   > And I need that loop-back stack, but it's not visible to the programmer either.
2022-12-20 08:53:17 <KipIngram   > And I may need a double buffer for the instruction word, since rep will require me to jump back to the start, and I've been shifting it.
2022-12-20 08:53:45 <KipIngram   > But maybe not - the initial pattern may still be available from the instruction RAM port.
2022-12-20 08:54:11 <KipIngram   > Maybe - may have incremented IP by then.
2022-12-20 09:02:41 <MrMobius    > it might not deploy the LUTs the way you envision. it might do it in a much better way :) I suspect the insane optimizing the software does is part of why the install is so enormous
2022-12-20 09:03:45 <KipIngram   > Well, it won't do better that the best it can do, in the example above of an arbitrary instruction encoding two LUTs per control bit is the best it can do.
2022-12-20 09:04:20 <MrMobius    > I would be skeptical that you designing in LUTs in your mind will beat the optimizer when someone designs the same thing with approach 1. we'll see though!
2022-12-20 09:04:21 <KipIngram   > I understand I don't fully control it, but I want it to have at least the opportunity to do an optimal result.  And, if it doesn't, like I said - I'd regard that as a shortcoming of the tool.
2022-12-20 09:04:53 <KipIngram   > Yes, I understand that the tools are quite good these days - it's the same with optimizing compilers.
2022-12-20 09:05:27 <KipIngram   > But... I first did this kind of work before there were any such tools.  We had to design EVERYTHING, explicitly.  It's just how I've learned to think.
2022-12-20 09:05:28 <MrMobius    > ya you wont beat an optimizing compiler by writing machine code 1 bit at a time
2022-12-20 09:05:50 <KipIngram   > If there is a "best possible way" and you find it, then it won't beat you either.
2022-12-20 09:06:04 <KipIngram   > I'm not arguing that the tool won't do a good job.
2022-12-20 09:06:15 <KipIngram   > Just that I want to know, from the outset, what is possible.
2022-12-20 09:07:12 <KipIngram   > And yeah, in a complex problem I might not be able to wrap my head around it enough to do as well as the tool.  But what I tend to do is idenfity critical parts of the system and try to make sure I have a clear understanding of what will be going on there.
2022-12-20 09:07:36 <KipIngram   > The discussion above isn't "the whole processor."  it's just one very critical aspect of it, and it's of a size that I can clearly picture it.
2022-12-20 09:09:13 <KipIngram   > Maybe I'm being an old-fashioned bigot here, but even if an engineer's approach 1 effort works great, I just wouldn't have the same level of respect for what he'd done.  I think at the very least approach 2 should be used.
2022-12-20 09:09:43 <KipIngram   > I don't regard it as "as good" as approach 3, but at least it's still "hardware engineering."
2022-12-20 09:10:27 <KipIngram   > I feel like the whole process of the last few decades has been to try to turn hardware design into software design, and I don't care for it.
2022-12-20 09:45:10 <KipIngram   > Maybe it's just hard for me to cope with having the world say "the thing you excelled at is no longer necessary."  That's not a particularly good feeling.
2022-12-20 09:45:36 <KipIngram   > But I feel sure that there are probably quite a few older, extremely skilled software engineers out there that feel the same way.
2022-12-20 09:46:22 <KipIngram   > When they began their career, they felt like wizards.  And now every kid on the block has their hand in the game and claims the same status.
2022-12-20 09:51:52 <veltas      > Oh you can definitely beat the compiler with your assembly, but the places where that is likely and relevant is getting smaller
2022-12-20 09:52:19 <KipIngram   > Yes, at best it probably matters only in a very small part of your code.
2022-12-20 09:52:33 <veltas      > As it is I have to do things people assure me are things the compiler should just "know how to optimise" and yet it doesn't, like the use of local static const arrays instead of just automatic arrays that don't change
2022-12-20 09:52:52 <KipIngram   > But I would argue that this opcode decoding stuff is such a place - it's probably the most important activity in the thing in terms of performance.
2022-12-20 09:53:03 <KipIngram   > It's something that needs to work as well as possible.
2022-12-20 09:53:51 <KipIngram   > I think the people who aren't as good at optimizing such things would be the first people to say "the compiler should do that for me.
2022-12-20 09:54:16 <veltas      > I think you're over generalising
2022-12-20 09:54:34 <thrig       > hilariously slow compile times in 3, 2,
2022-12-20 09:55:32 <KipIngram   > Probably.
2022-12-20 09:55:54 <veltas      > Hilariously slow dev times is what you get with assembly
2022-12-20 09:56:07 <KipIngram   > The conversation has got me thinking about it all and it's kind of a pet peeve - I might express things too strongly.
2022-12-20 09:56:40 <KipIngram   > Sounds to me like Chuck wasn't the fastest guy around in terms of dev time.  :-)
2022-12-20 09:57:21 <veltas      > There was a time when forth inc was producing decent database systems way before other people could, with more consistency and quality
2022-12-20 09:57:35 <veltas      > Probably when every mainframe was different and there were no decent off the shelf systems
2022-12-20 09:58:59 <KipIngram   > Makes sense.
2022-12-20 09:59:11 <KipIngram   > Maybe it helped to go directly to the disk instead of through a file system?
2022-12-20 09:59:27 <veltas      > I don't think "file systems" were typical back then
2022-12-20 09:59:37 <KipIngram   > Ok; that's fair.
2022-12-20 09:59:48 <veltas      > Honestly, Forth was quite a powerful environment back then
2022-12-20 09:59:49 <KipIngram   > File system facilitates you doing "extremely general" things with your disk.
2022-12-20 10:00:05 <KipIngram   > But if you have one very specific goal, you  might do better without one.
2022-12-20 10:00:17 <veltas      > And forth encourages incremental development
2022-12-20 10:00:26 <veltas      > Which I think is inherently useful most of the time
2022-12-20 10:00:34 <KipIngram   > Yeah, I agree.  It was cutting edge in its day.
2022-12-20 10:00:35 <veltas      > Keeps projects delivering and on track
2022-12-20 10:01:11 <veltas      > And people weren't relearning the dev env for every machine, the forth inc programmers worked with probably 90% the same code every time
2022-12-20 10:01:49 <KipIngram   > That's kind the idea I had re: that little pocket LCD panel gadget.
2022-12-20 10:02:02 <KipIngram   > Get it made and basically working, and then just slowly increment it along over time.
2022-12-20 10:02:19 <KipIngram   > I'd be able to pull it out of my pocket anytime, anywhere, and putz around with it.
2022-12-20 10:02:28 <KipIngram   > Add new things gradually.
2022-12-20 10:03:00 <KipIngram   > More for fun than anything else, but if I had it I'm sure I'd be interested in organization features.
2022-12-20 10:17:34 <veltas      > "More for fun than anything else" you just described almost everything in this channel
2022-12-20 10:18:07 <veltas      > The only practical use of forth I'm aware of in this channel is I use gforth as a calculator at work and crc actually uses retro for consultancy
2022-12-20 10:18:12 <thrig       > swing pays the bills. jazz is music
2022-12-20 10:20:27 <veltas      > One day I'm sure at work I'll have reason to embed some kind of interpreter or bytecode VM thing and then bam, Forth it is
2022-12-20 10:21:30 <veltas      > No honestly even then I probably won't, because I never want to have that conversation where I explain people need to train in Forth to maintain my software
2022-12-20 10:22:00 <veltas      > If you run your own company you can write Forth, that's pretty much it
2022-12-20 10:22:11 <thrig       > some lisp folks are quite happy to put a live coding environment into production that nobody else knows
2022-12-20 10:22:42 <thrig       > (they call this "stop writing dead programs")
2022-12-20 10:23:03 <veltas      > lol I've seen an article with that title
2022-12-20 10:23:52 <veltas      > Not a fan of lisp
2022-12-20 10:28:32 <veltas      > https://www.youtube.com/watch?v=8Ab3ArE8W3s
2022-12-20 10:31:43 <veltas      > Not a fan of this video either, the beginning is fun though
2022-12-20 10:37:53 <MrMobius    > I have a 6502 Forth I like so I run it in an emulator written in MIPS assembly that runs in QEMU in a terminal
2022-12-20 10:38:03 <MrMobius    > as a calculator
2022-12-20 10:38:42 <veltas      > Nice
2022-12-20 10:39:00 <veltas      > KipIngram: Honestly if you want to get down to bare bones on everything, why use Forth and not just assembly?
2022-12-20 10:48:21 <thrig       > oh hey 77 PDF files comprising the Graphics Programming Black Book. yoink
2022-12-20 11:01:24 <KipIngram   > Oh, because Forth actually can extend upward as far as I want it to.
2022-12-20 11:01:32 <KipIngram   > So, for the extensibility.
2022-12-20 11:01:55 <KipIngram   > I want to write the bare metal code, but I don't want to write ONLY bare metal code.
2022-12-20 11:02:12 <KipIngram   > And being able to do it all, bottom to top, in one language / method is satisfying.
2022-12-20 11:02:28 <KipIngram   > Basically Forth just strikes me as the best overall way to deal with computers that exists.
2022-12-20 11:02:47 <KipIngram   > Taking all aspects, everything you eventually  need to do, into account.
2022-12-20 11:02:57 <KipIngram   > ^^ Opinion, of course.
2022-12-20 11:03:52 <KipIngram   > So I see several points in this design I'm considering where I think I want to embed little small, "invisible" stacks in the system.  No explicit programmer management; they'll get operated by various opcodes.
2022-12-20 11:04:02 <KipIngram   > Distributed RAM may be ideal for those.
2022-12-20 11:05:18 <KipIngram   > For example, {| ... |} needs to save/restore three different items.  In my x86 system those get saved on the return stack.  But serializing that slows things down - in hardware I'll just have three small stacks that I push them to, pop them from.
2022-12-20 11:05:38 <KipIngram   > That one will be quite shallow, like 2-4 deep.
2022-12-20 11:06:05 <KipIngram   > But { ... } will also use two of them, and in that case they should be somewhat deeper, like maybe 8 or so.
2022-12-20 11:07:02 <KipIngram   > And if I'm going to dispense with indexing into the stack, then the data stack can be an isolated stack as well.  Chuck's stack depth has varied over the years - I can just explore how deep data and return need to be.
2022-12-20 11:07:25 <KipIngram   > I should instrument my system so that it can tell me the maximum stack depths encountered.
2022-12-20 11:08:11 <KipIngram   > Oh, and that loopback feature will have a stack.  That one will need to be however deep you want to  nest loops.  Eight is probably plenty there too.
2022-12-20 11:09:03 <KipIngram   > I don't think I have any loops in my existing system nested more that 3-4 deep.
2022-12-20 11:11:24 <KipIngram   > } is not going to drop extra items in the hardware - it will just put the stack back exactly how it was on {.  Except the TOS will carry whatever you've got in it after running the { ... } contained code; that's "the result."
2022-12-20 11:11:52 <KipIngram   > I'll do that cleanup manually using : nips ( n --) ...nip n times... ;
2022-12-20 13:09:17 <veltas      > I don't disagree
2022-12-20 16:24:56 <KipIngram   > Ok, I think this "extended" instruction set is causing irritation.  I think I should just do five 6-bit opcodes instead of six 5's, and have done with the issue.  Plenty of room for everythin and I can even add a couple that seem useful.
2022-12-20 16:25:35 <KipIngram   > Everythin's the same, and the instructions partition nicely into "no stack effect," "drop the stack," and "add to the stack."
2022-12-20 16:25:44 <KipIngram   > I'll be able to know that just from the encoding.
2022-12-20 16:29:05 <KipIngram   > That'll have slightly lower code density, but the real penalty of the change is that change is that after spending one on rep I'll have max four slots left for fast counted loops.
2022-12-20 16:39:40 <KipIngram   > Well, the opcodes partition "almost" nicely.  There are more than sixteen instructions that want to drop the stack, so two bits of the encodin won't fully identify that class.  There will have to be a small "other pattern" included in the "drop set" too.
2022-12-20 16:40:19 <KipIngram   > But "no chage" is identified by a single encoding bit, and "grow by one" is identified by two.
2022-12-20 17:11:15 <MrMobius    > Could you have one of the left over bits signal which of the extended sets the next six belong to?
2022-12-20 17:11:47 <MrMobius    > More burdeon on the programmer to remember to put them close and wastws memory but might be faster
2022-12-20 17:32:48 <KipIngram   > I think this gets things to where I can arrange the opcodes to do just about the fastest decoding I could ask for.
2022-12-20 17:33:03 <KipIngram   > We'll see, but at the moment I don't see a need for any tricky moves.
2022-12-20 17:33:51 <KipIngram   > This "stack effect" separation is just one grouping; hopefully I can further split things up to get more info from the instruction bits directly.
2022-12-20 17:34:29 <KipIngram   > Like, perhaps split each of these groups on how they affect the return stack, or whatever.
2022-12-20 22:52:18 <MrMobius    > wasnt someone asking about back issues of the German Vierte Dimension? looks like links here: https://forth-ev.de/wiki/vd-archiv