2022-04-06 08:20:30 <vms14       > I have vocabularies implemented and I think forget works fine
2022-04-06 08:20:48 <vms14       > but now I struggle a bit with the return stack
2022-04-06 08:21:12 <veltas      > What's the struggle?
2022-04-06 08:21:37 <vms14       > the thing is, words are arrays not memory locations, when you pop the return stack you can increment the ip as they are consecutive
2022-04-06 08:22:05 <vms14       > but as they're arrays I suppose I need to keep track of the current word being executed too
2022-04-06 08:22:41 <veltas      > Yep the array & index or just a pointer to current element would be needed
2022-04-06 08:22:44 <veltas      > If I understand you right
2022-04-06 08:22:58 <vms14       > haha sorry I try to understand my problem
2022-04-06 08:23:01 <veltas      > pointer/address
2022-04-06 08:23:24 <vms14       > https://termbin.com/qqa3 I have this, there are some comments idk if it's readable
2022-04-06 08:23:38 <vms14       > it just implements the dictionary and vocabularies
2022-04-06 08:24:05 <vms14       > and search which gives you the index of the word you want in the @dictionary array by looking at vocabularies in order
2022-04-06 08:24:23 <vms14       > and forget which removes the words and "updates" the vocabularies too
2022-04-06 08:24:50 <vms14       > now I need the return stack but I suppose I just need to keep track of the current word being excute
2022-04-06 08:29:09 <vms14       > I'll try it that way
2022-04-06 08:30:42 <vms14       > I have no idea about how to implement branch and alike, but need to get the return stack right first
2022-04-06 08:31:37 <vms14       > I have to go, ty veltas I think you helped me :D
2022-04-06 08:42:15 <KipIngram   > Well, I managed to successfully change my header layout as previously discussed.
2022-04-06 08:42:47 <KipIngram   > It was about the difficulty level I figured it would be - should have been simple but I hadn't been as "clean" as I ought to have, so a few things had to be chased down.
2022-04-06 10:31:33 <Zarutian_HTC> h'lo folks, one BitGrid related idea: for visualization of config show the bitgrid cells as 8x8 pixel bitmap tiles
2022-04-06 10:32:15 <Zarutian_HTC> each such tile is split up into four 4x4 quadrants
2022-04-06 10:33:06 <Zarutian_HTC> the quadrants are arranged thus: N E \n W S
2022-04-06 10:33:38 <KipIngram   > So it was clear that  BitGrid mapped the config RAM into standard RAM space externally accessible.  I didn't see that it said anything about the cell outputs, but it seems reasonable that that would be mapped into an additional section of RAM, right?
2022-04-06 10:33:47 <KipIngram   > That would be 4 bits per cell.
2022-04-06 10:34:08 <Zarutian_HTC> each quadrants is the 16 bit LUT contents for that output
2022-04-06 10:34:11 <KipIngram   > So a much smaller section of RAM.  But you'd still want to be able to know "the state," it seems.
2022-04-06 10:34:29 <KipIngram   > Although I guess given that the cells are deterministic you could calculate the outputs from the config easily.
2022-04-06 10:34:37 <KipIngram   > So maybe you wouldn't have extra hardware for that.
2022-04-06 10:34:50 <KipIngram   > That might be a large calculation, though.
2022-04-06 10:36:57 <Zarutian_HTC> KipIngram: not nescicarely, if you do not mind 'gaps' in your address space
2022-04-06 10:37:04 <KipIngram   > Also, were any clocks mentioned?  You can think of this thing being either sequential or combinational.
2022-04-06 10:37:37 <Zarutian_HTC> no clocks so I am assuming asynchronus
2022-04-06 10:37:55 <KipIngram   > That's what I thought too, though the idea works either way.
2022-04-06 10:38:14 <KipIngram   > Just a "sea of gates," with the gates "fully flexible."
2022-04-06 10:38:33 <KipIngram   > Each "gate" can implement any Boolean function of its inputs.
2022-04-06 10:38:36 <Zarutian_HTC> better without the clocks as they are limiting factor in many of todays fpgas iirc
2022-04-06 10:38:53 <KipIngram   > Yeah, it seems more "pure" without the clocks.
2022-04-06 10:39:26 <Zarutian_HTC> each BitGrid cell is a four input four output combinational device
2022-04-06 10:39:28 <KipIngram   > And if you had a clock, you'd be expecting it to be uniform across the array, and that can be hard to engineer.
2022-04-06 10:39:35 <KipIngram   > Right.
2022-04-06 10:39:50 <KipIngram   > So yeah, four flexible gates.
2022-04-06 10:40:35 <Zarutian_HTC> re visualization: I have not decided on how the 4x4 quadrant bitmaps are laid out
2022-04-06 10:40:52 <KipIngram   > It really strikes me as a sea of gates FPGA taken to the full extreme.  And with the config RAM accessible in a fully general way, it really does offer some very interesting notions of "dynamic evolution."
2022-04-06 10:41:07 <KipIngram   > You could re-write the config while it ran.
2022-04-06 10:41:16 <KipIngram   > Or parts of the config.
2022-04-06 10:41:38 <KipIngram   > I've wished for a while that FPGAs would let you do that.
2022-04-06 10:41:39 <Zarutian_HTC> which means that you can have signals/wires crossing over each other, etc
2022-04-06 10:42:32 <Zarutian_HTC> some Xilinx fpgas allow for that but it is hard because their bitstreams are not open spec
2022-04-06 10:42:35 <KipIngram   > The neighbor-to-neighbor connects would be pretty straightforward - it would be getting the address and data lines in and out for reading/writing the config that might get nasty.
2022-04-06 10:42:50 <KipIngram   > I know, and that bugs the hell out of me.
2022-04-06 10:43:02 <KipIngram   > Do they want people to use their parts or not?
2022-04-06 10:43:17 <KipIngram   > The way to promote use is to make the things as easy to use in as many ways as possible.
2022-04-06 10:43:28 <KipIngram   > I think they want to monetize the tool chain too.
2022-04-06 10:43:40 <KipIngram   > And I guess they worry that that info might allow competitors to reverse engineer.
2022-04-06 10:43:45 <Zarutian_HTC> re config lines routing, I am thinking Hilbert curve routing
2022-04-06 10:44:44 <Zarutian_HTC> that might be one of their concerns
2022-04-06 10:46:00 <Zarutian_HTC> but also there is option of encrypting the bitstream with aes which the fpga then decrypts using its inbuilt aes engine
2022-04-06 10:46:40 <Zarutian_HTC> that aes engine is also available as a hard block in the fpga btw
2022-04-06 10:47:06 <KipIngram   > Sure - I just meant that telling us which bits of the stream did what might reveal clues about the internal architecture.
2022-04-06 10:47:50 <Zarutian_HTC> this is understandable as many IntProp heavy companies do not want their trade secrets to abscond to their competion
2022-04-06 10:48:07 <KipIngram   > I've gotten an itch the last few days to do some FPGA work again.  I've been looking at eval kits online.
2022-04-06 10:48:44 <Zarutian_HTC> I heard of Symbiflow the open source project has a good listings of such
2022-04-06 10:49:03 <KipIngram   > I just installed that yesterday and ran through some of the examples.
2022-04-06 10:49:15 <KipIngram   > It installed easy and just in general didn't complain about anything.
2022-04-06 10:49:29 <KipIngram   > There were a good number of steps in the install, though.
2022-04-06 10:49:45 <KipIngram   > I was really happy to see that we have open source toolchains now.
2022-04-06 10:50:17 <KipIngram   > I'm really just a fan of *anything* that chinks away at the grips the big corporations have us in.
2022-04-06 10:50:27 <Zarutian_HTC> the funny thing is that Xilinx basic toolchain is availablr freely which means that some hackers have been reverse engineer the bitstream via basic oracle attacks
2022-04-06 10:50:58 <KipIngram   > You know, if those guys would just get a job they could be great engineers.
2022-04-06 10:51:02 <KipIngram   > They're plenty smart.
2022-04-06 10:51:37 <Zarutian_HTC> oh, these guys have jobs. The hacking is just side hobby
2022-04-06 10:51:41 <KipIngram   > I remember when I saw how Spectre/Meltdown worked I was really impressed.
2022-04-06 10:51:48 <KipIngram   > :-)
2022-04-06 10:52:29 <Zarutian_HTC> plus EULAs are quite unenforcable in many polities
2022-04-06 10:52:47 <KipIngram   > Good.  They've taken those things way to far.
2022-04-06 10:53:23 <KipIngram   > Oh, my wife told me last night that the coming trend in cars is that they want to make operation of features like heated seats and stuff a *subscription service*.
2022-04-06 10:53:24 <Zarutian_HTC> but the funny thing is that copyright licenses like GPL are
2022-04-06 10:53:30 <KipIngram   > That just blew my mind.
2022-04-06 10:54:08 <KipIngram   > They actually want you to pay the for having the feature in your car and then pay them every month for the privilege of using it.
2022-04-06 10:54:47 <Zarutian_HTC> I would not buy such a car, but perhaps long term rent one
2022-04-06 10:55:06 <Zarutian_HTC> but then again I do not like driving
2022-04-06 10:55:08 <KipIngram   > I know - me either.  But the idea itself just struck me as so over the top I could hardly believe it.
2022-04-06 10:55:24 <KipIngram   > Greed knows no bounds.
2022-04-06 10:55:56 <Zarutian_HTC> at least commuting via public transport I can read or listen intently to podcasts or audiobooks
2022-04-06 10:56:04 <KipIngram   > Sure.
2022-04-06 10:56:26 <KipIngram   > I do like driving my car, but I wouldn't go drive it around just for fun very much.
2022-04-06 10:56:54 <Zarutian_HTC> so, does the car contact some digital restriction management server at every start or?
2022-04-06 10:56:59 <KipIngram   > I just took it in for some body work yesterday.  I've driven around with an ugly caved in corner on the back bumper for the last year and a half or so.
2022-04-06 10:57:11 <KipIngram   > Just took that long to feel like enough surplus money was on hand.
2022-04-06 10:57:22 <KipIngram   > Because... there's always something.
2022-04-06 10:57:49 <KipIngram   > So I'm looking really forward to having her all shiny and beautiful again.  :-)
2022-04-06 11:00:21 <Zarutian_HTC> re BitGrid: I am longing/hoping that such chips would become as jellybeanish as the 7400's and such chips are
2022-04-06 11:00:39 <KipIngram   > Yes - that would be great.
2022-04-06 11:00:54 <KipIngram   > I think there's huge creative opportunity available there.
2022-04-06 11:05:34 <Zarutian_HTC> starting off with say 20x20 grid chip in MQFP with 96 pins would be groovy
2022-04-06 11:06:21 <KipIngram   > That would be fun.  I was hoping that eventually they could be much much larger - likes millions of cells.
2022-04-06 11:06:57 <KipIngram   > Like the pixels in our displays.  :-)
2022-04-06 11:07:11 <KipIngram   > Veritable ocean of logic.
2022-04-06 11:07:14 <Zarutian_HTC> it is the gate propagation speed I am concernef about
2022-04-06 11:07:33 <KipIngram   > Yes, for sure - that would have to be considered in the design.
2022-04-06 11:07:46 <KipIngram   > As the thing got bigger it would be more and more impossible to ignore it.
2022-04-06 11:08:02 <KipIngram   > And if it's combinational, the dynamics that could start to appear would be fascinating.
2022-04-06 11:08:35 <KipIngram   > I think recognizing that delay would have to be an overt part of your thinking on large grids.
2022-04-06 11:09:03 <Zarutian_HTC> plus the one I specified above would be useful and manifacturable open source ecology wise
2022-04-06 11:09:28 <KipIngram   > That would be smashing.  The more open source the better.
2022-04-06 11:10:17 <Zarutian_HTC> so BitGrid blocks and bus routing blocks checkered together would work better I hold forth
2022-04-06 11:11:15 <KipIngram   > Yeah, I guess you could have all manner of arrangements of that type.
2022-04-06 11:11:40 <Zarutian_HTC> bus routing blocks are pretty easy to design: per output of the block have a mux that selects between inputs of the block
2022-04-06 11:12:17 <KipIngram   > Yeah - when you start thinking "on chip" you have to turn off your "high impedance concept" switch.
2022-04-06 11:12:24 <Zarutian_HTC> two constant inputs (or just one): all zeros, all ones, needs to be in that set
2022-04-06 11:22:02 <Zarutian_HTC> so the 20x20 chip above can be used in conjunction with other chips such as eeprom such as 24c16 or srams with parallel interface and you can get your own custom mcu like thing
2022-04-06 11:27:06 <Zarutian_HTC> hmm BitGrid blocks plus routing boxes above: one/few of the 'outputs' of such a box would be the config memory access port of a neighbouring BitGrid block
2022-04-06 11:28:47 <Zarutian_HTC> which means that you could reconfigure easily and if you do not need that BitGrid block for logic, use it as memory block
2022-04-06 11:32:51 <Zarutian_HTC> stealing a page out of Harris RTX 2010 design one could get a small Forth computer out of four such BitGrid blocks: one in middle for the logic and three neighbours for the memories
2022-04-06 11:34:17 <Zarutian_HTC> one for datastack, one for returmstack, and one for wram/pram
2022-04-06 11:34:48 <Zarutian_HTC> s/turm/turn/
2022-04-06 12:15:00 <KipIngram   > Ok, I purged that "count byte MSB set" from the system.  So now the name strings are first class Forth counted strings instead of "hacked" counted strings.
2022-04-06 12:15:20 <KipIngram   > What motivtaed this yesterday was that I did some timing comparisons between my system and GForth.
2022-04-06 12:16:05 <KipIngram   > On the execution of compiled code, I did quite well - I first created a loop that was as close as possible, given my system, to a GForth loop I timed.  I was a little slower, but only a few percent.
2022-04-06 12:16:34 <KipIngram   > On top of that, my "added words" (conditional return) let me re-write that same loop in a different way, and that ran 15% faster than the GForth loop.
2022-04-06 12:16:37 <KipIngram   > So, good.
2022-04-06 12:17:04 <KipIngram   > But then I used the >in reset trick to time loops over interpreted actions (dictionary search and number conversion, primarily).
2022-04-06 12:17:10 <KipIngram   > And GForth just kicked my ass.
2022-04-06 12:17:30 <KipIngram   > I strongly suspect that they've got some good native code support somewhere down in FIND.
2022-04-06 12:18:09 <KipIngram   > So, I'm interested in replacing that deepest loop, the one that compares the strings, with some suitable primitive support, and a primitive that compares counted strings and leaves a flag looks like the right way to go about that.
2022-04-06 12:18:16 <KipIngram   > Then I'll compare again and see where we are.
2022-04-06 12:18:47 <KipIngram   > Their FIND has at least a few top levels that are Forth, because I can SEE them.
2022-04-06 12:18:58 <KipIngram   > But it's that deepest loop that has the most impact anyway.
2022-04-06 12:20:31 <KipIngram   > That high MSB bit in the dictionary names was complicating the application of a "general compare word" to the task.  But... gone now.
2022-04-06 13:00:03 <Zarutian_HTC2> KipIngram: that sounds nice
2022-04-06 13:01:09 <Zarutian_HTC> and iirc, IBM 370 has an block compare instruction which I found strange
2022-04-06 13:02:26 <Zarutian_HTC> though myself would just implement that function as a routine
2022-04-06 13:03:44 <Zarutian_HTC> basically count down loop whose body is to fetch the two machine-words, xor them together and or that result into an accumulator register
2022-04-06 13:18:42 <KipIngram   > It's better - every since one of us mentioned that a dictionary would be better if the name came at the end of the record, I've pouted a little over mine not being that way - it's clearly a right idea.  I refined it a little by putting the PFA first, with the CFA being second and the "anchor" of the record.  Because primitives don't need a PFA field - it's "optional."  What really got me off the dime, though,
2022-04-06 13:18:45 <KipIngram   > was the notion of being able to use a fast string compare primitive.
2022-04-06 13:19:11 <KipIngram   > At the moment I'm re-working my FIND so that it invokes an explicit string compare operation, which I'll initially write in Forth but will be able to replace with such a primitive.
2022-04-06 14:49:08 <remexre     > Zarutian_HTC: I think the modern-x86 viewpoint is that you want a hw insn for {mem,str}{cpy,cmp,move}, because they're often performance-sensitive and the cycle-optimal implementation can be heavily uarch-dependent
2022-04-06 15:32:28 <Zarutian_HTC> remexre: well legacy x86 is pretty consistant with other CISCs
2022-04-06 16:13:16 <Zarutian_HTC> ... in that regard
2022-04-06 16:14:05 <Zarutian_HTC> sorry got distracted, then I had to make dinner and I just noticed now the missing bit
2022-04-06 19:43:15 <KipIngram   > This is fun:
2022-04-06 19:43:17 <KipIngram   > https://www.youtube.com/watch?v=FyCYva9DhsI
2022-04-06 19:43:30 <KipIngram   > And scarily evocative of the real world.
2022-04-06 20:51:30 <KipIngram   > Wow - I watched that whole thing.  Very entertaining.
2022-04-06 22:31:38 <KipIngram   > I suppose GForth uses hashing for its dictionary search.
2022-04-06 22:31:58 <KipIngram   > What I'm measuring seems too fast to be anything else.
2022-04-06 22:39:18 <KipIngram   > Yeah - I think I've proven pretty conclusively they're hashing.
2022-04-06 22:39:44 <KipIngram   > I expect they build it up as they're gathering bytes from the input stream, so it's ready to go when they get to the space.
2022-04-06 22:39:52 <KipIngram   > It's what I'd do.
2022-04-06 22:55:17 <KipIngram   > Anyway, I defined the tib-loop word using a 45-character name and measured it.  That came out around 260 NANOSECONDS  per iteration.  An iteration involves parsing the word from the input buffer, finding it in the dictionary, and executing it.
2022-04-06 22:55:50 <KipIngram   > Then I defined five more 45-character long names, each of which differed from the first in just one character somewhere in the string.  So, no "count by discrimination."
2022-04-06 22:56:14 <KipIngram   > I measured that again.  The time per iteration hardly budged.
2022-04-06 22:56:56 <KipIngram   > i fibbed though - I'm sorry.  The 260 ns was for the name "tib-loop."  The 45-char name took it up to 350 ns.
2022-04-06 22:57:19 <KipIngram   > But still.  The point is that the need to "search past" five equal length, near match names didn't slow it down AT ALL.
2022-04-06 22:57:23 <KipIngram   > so - it's not doing that.
2022-04-06 22:57:28 <KipIngram   > It's hashing.
2022-04-06 22:59:52 <KipIngram   > Anyway, mine takes about 10.4 microsecond to parse, find, and execute "tib-loop," and it only goes up to 11.5 us for a 45 char name.  (I've installed a string match primitive now).
2022-04-06 23:00:20 <KipIngram   > I haven't tried the 5 extra names on mine yet - I don't have command history so I'd have to type them all out by hand - ugh.
2022-04-06 23:00:31 <KipIngram   > Guess I could paste.
2022-04-06 23:01:20 <KipIngram   > Anyway, as far as I can tell the new primitive leaves me with my actual string matching time being a fairly small fraction of my overall effort, which was the point, of course.
2022-04-06 23:10:00 <KipIngram   > Anyone know how to "more" the GForth word list?  when I type 'words' it just scrolls right off the top of the page.
2022-04-06 23:10:07 <KipIngram   > I can't see the first words it outputs.
2022-04-06 23:35:58 <KipIngram   > Unless there's a mechanism for paging it, I question the utility of having such a word.
2022-04-06 23:38:33 <KipIngram   > Oh - ok.
2022-04-06 23:38:53 <KipIngram   > gforth --evaluate "words bye" >output