2022-12-28 00:02:06 <KipIngram   > Ok.  I think I've sketched out all of the "subtle" parts of this thing now.  There are a few odds and ends still undrawn, like the address registers, a config register I know I'm going to need, etc.  But those are all "very simple and straightforward" things.  I think I've now got all of the delicate pieces in mind.
2022-12-28 00:02:27 <KipIngram   > Now I just need to go through it all again, carefully, and make final drawings.
2022-12-28 00:02:37 <KipIngram   > With no corners cut.
2022-12-28 01:23:52 <KipIngram   > Well, I think the simplest way to handle external RAM is to just put in my own nop cycles.  Instead of >a a@ or >b b! I'd have >a nop a@ or >b nop b! *as required*.  The nice thing about that is that I could always try to arrange to have some actual instruction to run in between.
2022-12-28 01:24:08 <KipIngram   > And if I ever wanted to it would be an easy thing to write the compiler to do for me.
2022-12-28 01:25:09 <KipIngram   > Well, sometimes.
2022-12-28 01:25:40 <KipIngram   > To the extent I could tell at compile time which type of RAM the operation was destined for.
2022-12-28 01:25:55 <KipIngram   > Who knows?  It  may wind up being that that's rare.
2022-12-28 01:26:19 <KipIngram   > Anyway, the typical SRAM speeds I've seen on digikey the lsat day or two are in the 8ns-10ns range.
2022-12-28 01:27:06 <KipIngram   > And for streaming the data out to an LCD I don't need to actually pass the data through the stack - the circuiry that does that will just advance the address at the appropriate rate and insert the retrace delays where suitable.
2022-12-28 01:28:11 <KipIngram   > One thing I could possibly do is write the code so that when I do modifications on the display RAM it buffers the operations somewhere and then writes a batch of them out after getting a "retrace interrupt."
2022-12-28 01:30:56 <KipIngram   > That circuitry will use it's own internally generated address to write to the RAM "normally," but when it posts that retrace interrupt it would flip a bit such that the processor address registers produced that address.  So I could do normal writes.  It would flip it back automatically when it was time to write the next frame / line.
2022-12-28 01:31:09 <KipIngram   > And it would just be up to me to make sure I didn't try to write new stuff out for two long.
2022-12-28 01:31:24 <KipIngram   > The writes would just stop working if I tried to do too much.
2022-12-28 01:33:31 <KipIngram   > Oh, actually there would be no need for the nop in the >b nop b! sequence unless I was about to do another RAM operation.  The processor doesn't need that delay to clock the right addr/data out.
2022-12-28 02:33:17 <KipIngram   > You know, here's a blue-sky idea.  I have these two extra bits in each 32-bit control word that define the usage of that cell.
2022-12-28 02:33:55 <KipIngram   > The cases I've used are a) five packed opcodes, b) Forth call to an address, c) Forth jump to an address (tail optimization).
2022-12-28 02:34:17 <KipIngram   > I have the opcode level "me" mechanism and also the cell-level rep mechanism for jumps within a word.
2022-12-28 02:34:24 <KipIngram   > Ok, but there's a fourth case available.
2022-12-28 02:34:42 <KipIngram   > One possibility would be d) word contains two 15 bit call addresses.
2022-12-28 02:35:17 <KipIngram   > Wouldn't be usable in all situations, but my gut feel is that it would be *often* usable.  The addresses could be either absolute or relative.
2022-12-28 02:35:28 <KipIngram   > That would result in a DRAMATIC reduction in code size.
2022-12-28 02:35:50 <decay       > I have a feeling you'd like transport-triggered architectures, KipIngram.
2022-12-28 02:36:13 <KipIngram   > I don't konw what that is, but I will look it up.
2022-12-28 02:36:43 <decay       > your code directly drives the connection between processor elements instead of being decoded to those signals.
2022-12-28 02:37:30 <KipIngram   > Oh, doesn't that make the instruction words a lot bigger?
2022-12-28 02:37:50 <KipIngram   > Almost all of my control signals in this design can be produced with a single LUT.
2022-12-28 02:37:56 <decay       > it can or it can't. the simplest instruction is "connect X to Y".
2022-12-28 02:38:01 <KipIngram   > since 6-bit opcodes and 6-input LUTs.
2022-12-28 02:38:18 <KipIngram   > Sounds a little like dataflow.
2022-12-28 02:40:33 <KipIngram   > Anyway, this would add some extra complication in ir_control.  I'm only teasing with the thought because it would, in fact, shrink the code so much.
2022-12-28 02:44:38 <KipIngram   > Oh, looking at it on Wikipedia.  Yeah, that is a "view" of things I like.  It is, after all, what's REALLY happening.
2022-12-28 02:44:57 <KipIngram   > You transport stuff from where it's stored to the ALU inupts, you transport the ALU output to the destination.
2022-12-28 02:45:00 <KipIngram   > And so on.
2022-12-28 02:45:09 <KipIngram   > That's exactly the level I think at when I do this kind of work.
2022-12-28 02:45:32 <KipIngram   > Then you go through and make sure that your clock period is long enough for all the right stuff to happen.
2022-12-28 02:45:57 <KipIngram   > Another way of saying is that you "transport register outputs to combinational circuit inputs."
2022-12-28 02:46:08 <KipIngram   > And load registers from combinational circuit outputs.
2022-12-28 02:46:13 <KipIngram   > It's the whole game.
2022-12-28 02:47:14 <KipIngram   > That's probably the clearest view there is of what a computer "does."
2022-12-28 02:48:06 <KipIngram   > It's the right level to think about if you have to design the hardware.
2022-12-28 02:49:23 <KipIngram   > It's like supplying the differential equation of motion in a physics problem, because that differential equation is what turns 'state now' into 'state a short time later.'
2022-12-28 02:49:40 <KipIngram   > The combinational logic is the computer's "equation of motion."
2022-12-28 02:52:03 <KipIngram   > It may turn out someday that the whole universe works that way, using the Planck time as the "clock period."
2022-12-28 02:52:13 <KipIngram   > That's pretty speculative, though.
2022-12-28 03:01:28 <KipIngram   > Hey, pretty astute call, decay.  That really connects with this recent work gracefully.
2022-12-28 03:03:10 <KipIngram   > In my case, each step is a "set" of transports.  I might move things around in several places, relying on the fact that they're happening on the same clock edge.
2022-12-28 03:03:49 <KipIngram   > I may be sending "now TOS" somewhere and sending something else into "next TOS."  If they weren't all guaranteed to happen in parallel, the the result would depend on the order things were done in.
2022-12-28 03:04:36 <KipIngram   > That's why I've commented from time to time that I think "basic training" for digital EE guys promotes a smoother adoption of threaded programming than the early phases of software training does.
2022-12-28 03:04:55 <KipIngram   > We just never get that "sequential mind set" baked in to the same extent.
2022-12-28 03:09:05 <KipIngram   > Well, actually we do a little, but instead of it being "this and then that," it's "this and that AT THE SAME TIME."
2022-12-28 03:09:28 <KipIngram   > Then we get a little further and learn that that "at the same time" qualifier if iffy if we're not careful.
2022-12-28 03:09:39 <KipIngram   > And that's where we learn about setup and hold times.
2022-12-28 03:13:48 <decay       > ;)
2022-12-28 03:22:41 <decay       > you could use this to your advantage to have a smaller processor design.
2022-12-28 03:22:50 <decay       > smaller and more modular.
2022-12-28 03:24:48 <decay       > one of my earlier designs had an input buffer full of instruction words ("connect A to B"/"send A to B") that each of the modules could write to. so your program counter (and program _memory_) needed to be a separate module that you could address.
2022-12-28 03:25:39 <decay       > the _advantage of that_... was that you suddenly had concurrent execution for free.
2022-12-28 03:25:58 <decay       > and your programs could include a simple scheduler that could control everything at the gate level.
2022-12-28 05:48:25 <veltas      > Literally seconds before a junction the overhead signs changed saying "turn off at next exit", then signs ahead changed saying "all lanes closed". So I got off
2022-12-28 05:48:46 <veltas      > A lorry overturned, blocking 5 lanes on the motorway, would have been stuck there for like 5 hours
2022-12-28 05:49:13 <veltas      > Well actually looks like they've let people turn around and drive wrong way, but hours nevertheless
2022-12-28 10:53:00 <KipIngram   > Thank god for occasional common sense.
2022-12-28 10:53:12 <KipIngram   > Re: the letting folks drive the wrong way thing.
2022-12-28 10:54:31 <KipIngram   > Glad you dodged that.
2022-12-28 10:54:35 <thrig       > obviously the British side is correct; otherwise, the lance would be held wrong
2022-12-28 12:20:11 <KipIngram   > Well, I just bit the bullet an ordered one of those Swiss Micro calculators.  The DM41X, since it's basically a "clone" of my college calculator.
2022-12-28 12:20:36 <KipIngram   > Wasn't willing to spring for the express shipping, so I'll have to wait a while for it.  Impatient already.  :-)
2022-12-28 12:21:02 <KipIngram   > Could be as long as a month, but they say "usually faster."
2022-12-28 12:23:12 <KipIngram   > I have altogether too many calculators now.
2022-12-28 12:30:02 <KipIngram   > I also have two of those "after market mod" ones that I mentioned the other day; I bought one and later couldn't find it so bought another, then found the first one.  WP-34S.
2022-12-28 12:30:32 <KipIngram   > And I've got an "anniversary edition" they made of the HP-35S.  I wanted that one because it was manufactured "old style" with the good keys.
2022-12-28 12:30:53 <KipIngram   > Then I've got to TI nspire cx units that the kids used at some point in high school and I've somehow inherited.
2022-12-28 12:31:04 <KipIngram   > And I've also got a TI-84 variant.
2022-12-28 12:31:28 <KipIngram   > So that's six calculators; the DM-41X will make it seven.  Getting to be quite a collection.  :-)
2022-12-28 12:31:50 <KipIngram   > The TI-84 also came from a daughter at some point.
2022-12-28 12:32:15 <KipIngram   > They're all in a drawer of my nightstand.
2022-12-28 13:21:20 <lispmacs[work]> I've got quite a few TI calculators, including some -83s, an -86, an -84, and a -92
2022-12-28 13:24:50 <lispmacs[work]> I was very interesting at one point in learning how to program them, and running alternative OSs on them, but ran into a lot of trouble trying to get the TILP stuff working on my Guix system
2022-12-28 13:25:03 <lispmacs[work]> I was able to get it to work for my -89
2022-12-28 13:25:19 <lispmacs[work]> and then one my children dropped the -89 in a toilet
2022-12-28 13:28:24 <lispmacs[work]> he was quite young and didn't mean any harm, but wasn't able to get the -89 working again
2022-12-28 13:30:01 <KipIngram   > :-)
2022-12-28 13:30:10 <KipIngram   > Children: elementals of destruction.
2022-12-28 13:30:20 <KipIngram   > I think they totally explain the second law of thermodynamics.
2022-12-28 13:46:43 <nuck[m]     > My sons got some Transformers for Christmas, included a two-headed dragon one.  Shall we name it Swap-Swap?
2022-12-28 13:46:52 <nuck[m]     > 
ACTION uploaded an image: (92KiB) < https://libera.ems.host/_matrix/media/v3/download/trad.chat/NdGePgLSCmStButHUUitwffg/IMG_20221228_124544.jpg >

2022-12-28 14:06:42 <KipIngram   > Ah, groovy.
2022-12-28 14:07:05 <KipIngram   > I thought the first couple of Transformers movies were pretty good.
2022-12-28 14:07:21 <KipIngram   > And Megan Fox was especially good.  :-)
2022-12-28 14:07:48 <KipIngram   > There's a character in my favorite book series that I think she at that age would have been ideal for.
2022-12-28 14:08:29 <KipIngram   > Maeve, the "Winter Lady" (generally think Winter princess), and she's all-round dangerous to have around.
2022-12-28 14:09:01 <KipIngram   > Thoroughly irresistable and uses it constantly.
2022-12-28 14:32:43 <veltas      > Winter princess as opposed to turkish delight queen
2022-12-28 14:35:48 <KipIngram   > :-)  I don't immediately think of a character that matches that.
2022-12-28 14:36:17 <KipIngram   > In those books there's the Fairy Courts, Winter and Summer, and there are several flavors of vampire Courts.
2022-12-28 14:36:35 <KipIngram   > Three, actually - Black, Red, and White.
2022-12-28 14:37:03 <KipIngram   > Black is the most like a Stoker-style vampire.  Reds aren't too terribly different; still feed on blood, but they can make themselves look better.
2022-12-28 14:37:16 <KipIngram   > White Court vamps are basically succubi.
2022-12-28 14:37:38 <KipIngram   > The most prominent ones, at least - some feed on other emotions than lust.
2022-12-28 14:38:41 <thrig       > https://www.savagechickens.com/2009/10/yappy-dog.html
2022-12-28 14:39:55 <KipIngram   > So aside from my data stack, none of the other stacks are going to have register cached top items.  The others will just have a top element addressed, and I'll work directly with the block ram as though it's a register.
2022-12-28 14:40:43 <KipIngram   > Don't need the registers, because those stacks never do the fancy motions like swap and over and nip and so on.
2022-12-28 14:45:03 <veltas      > KipIngram: white witch from narnia
2022-12-28 14:50:34 <KipIngram   > Well, the books have wizards.  Main character is a wizard.
2022-12-28 14:51:09 <veltas      > I mean the "turkish delight queen" is the white witch from narnia
2022-12-28 14:51:15 <KipIngram   > Ah.
2022-12-28 14:51:46 <KipIngram   > I just started a new series with main character Alex Verus.  London-based "mage."  Sees the future.
2022-12-28 14:51:58 <KipIngram   > Or futures, rather.
2022-12-28 14:52:13 <KipIngram   > It's ok so far, but I don't really have an "opinion" yet.
2022-12-28 14:52:43 <veltas      > Weirdly I think to 'get' fantasy you need to start with the bible, and then stuff like beowulf and fairy tales, then lord of the rings
2022-12-28 14:53:17 <veltas      > They're pretty much essential to understanding fantasy
2022-12-28 14:56:47 <thrig       > or Gilgamesh, which totally rips off the whole Noah's Ark thing
2022-12-28 14:57:32 <KipIngram   > Oh, I agree.  If you just approach it as all made up then it's not terribly interesting.
2022-12-28 14:57:47 <KipIngram   > But if you can look for how the author has exploited real lore, now that can get fun.
2022-12-28 14:58:03 <KipIngram   > Most of the really ancient cultures had flood myths.
2022-12-28 14:58:13 <KipIngram   > Who ripped off whom becomes... hard to pin down.
2022-12-28 14:58:32 <KipIngram   > Gilgamesh is Sumerian and actually pre-dates the Old Testament.
2022-12-28 14:59:18 <KipIngram   > It all got to be a big melting pot of shared lore.
2022-12-28 14:59:48 <KipIngram   > We just happen to live in a culture that puts special significance on a particular thread of mythology.
2022-12-28 15:00:25 <KipIngram   > The books I like and mentioned above - the author does a REALLY good job of weaving all that old stuff into things.
2022-12-28 15:02:05 <KipIngram   > One fun twist is that it comes up (as a minor sidebar - not a big story element) that the White Court of vampires precipitated Bram Stoker writing his books - they did it to get a "how to kill Black Court vampires" how-to-guid into the hands of the public.
2022-12-28 15:02:32 <KipIngram   > As a result, the Blacks, once the dominant vampire lineage, got all but exteriminated, with only the most capable and strongest still floating around.
2022-12-28 15:02:45 <KipIngram   > Pretty much ended them as a "political faction."
2022-12-28 15:17:35 <veltas      > crc: So how is ilo encoded then? Are the 5-bit opcodes packed into cells? Or one operation per cell?
2022-12-28 15:18:06 <crc         > Four instructions per cell
2022-12-28 15:19:33 <veltas      > And how does IP work then? Are all four executed in a batch?
2022-12-28 15:19:46 <veltas      > Or is IP byte addressed
2022-12-28 15:20:59 <crc         > https://pastebin.com/raw/dMXKC1fV
2022-12-28 15:21:53 <crc         > A cell is fetched; each instruction is processed sequentially, but all addressing is cell based
2022-12-28 15:22:21 <veltas      > Thanks
2022-12-28 15:22:40 <crc         > no problem
2022-12-28 15:22:49 <veltas      > The C code explains it well
2022-12-28 15:22:54 <veltas      > Good C code goes a long way
2022-12-28 15:23:53 <crc         > fossils.retroforth.org:8000/ilo/file?udc=1&ln=on&ci=trunk&name=ilo.c is the  C code for the VM
2022-12-28 15:24:37 <veltas      > That's awesome
2022-12-28 15:24:51 <veltas      > See, to me that's actually easier to read than the docs you posted the other day lol
2022-12-28 15:25:02 <crc         > I also have nim, lua (requires a build w/32-bit integers), python3, and a few assembly (x86, amd64, aarch64) versions
2022-12-28 15:25:36 <veltas      > Everybody reading please take a moment to skim that VM's source code, it won't take you long
2022-12-28 15:26:43 <veltas      > So basically it runs everywhere
2022-12-28 15:27:25 <veltas      > How large is your retro image in bytes?
2022-12-28 15:28:03 <crc         > Yes. I've built it for DOS, Mac System 5/6/7, and a wide variety of newer systems
2022-12-28 15:33:00 <veltas      > crc: I'm sort of interested in concept of porting this to ZX Spectrum now, although it would be limited to something like 8K cells, think it would fit?
2022-12-28 15:35:02 <crc         > 8k cells would be tight. The base system is 3818 cells; but I reserve 5,536 cells (not all used) for various system things (tib, sigils, temporary strings & arrays, etc)
2022-12-28 15:36:23 <crc         > I'll do some tests to see how small I can go with it
2022-12-28 15:37:49 <veltas      > The absolute maximum amount of RAM you have is 10.5K cells, but some of them are slower to access
2022-12-28 15:39:37 <veltas      > crc: Does the basic image assume some kind of ANSI terminal for I/O?
2022-12-28 15:41:47 <veltas      > Also is there some assumption of hard storage
2022-12-28 15:43:42 <veltas      > Ah I see in the VM, silly question
2022-12-28 15:44:13 <crc         > No assumptions of an ANSI terminal
2022-12-28 15:44:15 <veltas      > Technically I could have load-image/save-image work with tape, but I can ignore that at first
2022-12-28 15:46:42 <crc         > The VM defines a generic block storage device. The image saving isn't strictly necessary, it's just nice to have
2022-12-28 15:47:21 <veltas      > Yeah
2022-12-28 15:48:28 <veltas      > Do you use a tiny font?
2022-12-28 15:51:21 <veltas      > How does it clear the screen then? It has to assume some kind of escape sequences right?
2022-12-28 15:54:04 <crc         > In the default system, I don't clear the screen. I just use it as if I were on a simple line terminal.
2022-12-28 15:56:16 <crc         > For fonts; on my phone, yes; a small font (I use an external keyboard, with font sized to give me about 21 lines and at least 72 columns). On desktop, I go with 80x25, and as large as I can. The optional graphical builds use an 8x16 font presently, on a 720x720 display (with pixel doubling on higher resolution displays if they can fit it).
2022-12-28 15:57:05 <crc         > There's an optional vocabulary that makes use of ANSI/VT100 escape sequences; it's not required, and I use it sparingly.
2022-12-28 16:00:03 <veltas      > manual clears the screen
2022-12-28 16:00:16 <veltas      > That's all I mean
2022-12-28 16:02:27 <veltas      > What control characters are required then, \n \r \t and \b ?
2022-12-28 16:04:35 <veltas      > spectrum just has a display buffer, no 'terminal', so I would need to implement that logic and keyboard scanning
2022-12-28 16:05:22 <KipIngram   > Do you have a call opcode, or just execute xt address cells when you come to them?
2022-12-28 16:06:58 <KipIngram   > Sounds like you're set up a lot like I'm doing, only packing in bytes because that's what a processor can unpack cheaply.
2022-12-28 16:21:12 <crc         > 
ACTION mostly reads the manual using the block editor directly. Just \n \r \t \b should be sufficient.

2022-12-28 16:21:33 <crc         > KipIngram: there's a call instruction; it takes an address from the stack
2022-12-28 16:23:48 <crc         > The forth is basically a direct threaded thing, with an optional assembler for writing new primitives or for things needing more performance.
2022-12-28 16:24:46 <veltas      > Are you allowed to define machine-specific opcodes then?
2022-12-28 16:28:09 <crc         > I have experimented with doing that
2022-12-28 16:28:58 <crc         > on memory use: reducing the size of the string/array pool by half (so just four entries) and leaving out the reserved-for-future-use parts of the buffers would reduce the memory footprint of the buffers to under 1,780 cells. (Of this, 1025 are for the block buffer)
2022-12-28 16:29:03 <crc         > This would give a minimal memory footprint at just under 5,600 cells for a base system.
2022-12-28 16:31:07 <crc         > Dropping the block editor & block buffer would save ~2000 cells, but I'd be reluctant to do that.
2022-12-28 16:33:24 <veltas      > But what good is a block editor / block buffer without a hard drive?
2022-12-28 16:33:53 <veltas      > You'd need to 'write' to a section of RAM, before writing out to tape
2022-12-28 16:37:03 <crc         > running on a tape based system would be different; it's not something I've done thus far
2022-12-28 16:38:21 <decay       > the "bundle" concept is interesting.
2022-12-28 16:38:41 <decay       > especially with things that look ahead like the literal push.
2022-12-28 16:40:09 <veltas      > It seems to inherently make sense with a word-addressed system
2022-12-28 16:40:35 <decay       > definiitely.
2022-12-28 16:41:00 <decay       > it's also inherently useful if you want to shortcut certain operation patterns.
2022-12-28 16:41:47 <decay       > instead of performing, say, 4 operations individually, if you know that some integer value corresponds to a small program, you can just write a switch/case to handle that.
2022-12-28 16:42:57 <decay       > a bunch of loads from memory for example can be done in a single pass.
2022-12-28 16:43:17 <decay       > or a "load load add store" can be done in a single pass.
2022-12-28 16:43:50 <decay       > it'll save you a shot through the inner switch for individual ops.
2022-12-28 16:44:15 <crc         > my son has a branch of the vm where he does that
2022-12-28 16:44:30 <decay       > he's a good son. ;)
2022-12-28 16:46:49 <veltas      > That's cool that you have a son that is into the same kind of programming, and programming at all
2022-12-28 16:47:01 <veltas      > I hope if I have kids at least one of them is into programming lol
2022-12-28 16:47:16 <veltas      > Bonus if they're into Forth
2022-12-28 16:54:27 <crc         > I have four boys; both of the older two can program, my second oldest uses Forth. The younger two aren't interested in programming yet
2022-12-28 16:54:55 <veltas      > Nice
2022-12-28 16:59:07 <veltas      > GNU sed is really not that optimised is it
2022-12-28 16:59:28 <veltas      > It's good for some things and really dumb for others
2022-12-28 16:59:49 <decay       > someone wrote a lisp in sed. I guess that's a benchmark.\
2022-12-28 16:59:59 <decay       > time for someone to write a forth in sed.
2022-12-28 17:06:51 <veltas      > Time for someone to write a sed in forth more like
2022-12-28 17:08:44 <thrig       > or benchmark sed against a sh while read line loop for lols
2022-12-28 17:08:50 <veltas      > crc: You require a C99 compiler, not C89, because you don't return from main
2022-12-28 17:09:18 <veltas      > If you return 0 from main at the end it would be compatible with C89 as well (although this will only affect exit code so not a big deal)
2022-12-28 17:23:07 <crc         > veltas: I'll fix that tonight
2022-12-28 17:24:22 <veltas      > Also if C23 is accepted with the decision to remove K&R-style functions then I think you will have to put explicit void or V in parentheses for function definitions with no arguments
2022-12-28 17:25:21 <veltas      > Although they could have changed the syntax to allow no 'void', I don't actually know
2022-12-28 17:27:57 <veltas      > I'm asking #c because I don't know
2022-12-28 17:33:24 <veltas      > Okay in C23 it will actually be prototyped, so no syntax change required
2022-12-28 17:33:35 <veltas      > This is good because the alternative was going to break a lot of code!
2022-12-28 17:50:25 <crc         > If I was targeting C23, I'd just do a separate source file for that.
2022-12-28 18:01:16 <KipIngram   > I have five daughters, but none of them into Forth, and actually none of them SERIOUSLY into programming.
2022-12-28 18:01:33 <KipIngram   > Not really.  They've been exposed to some special purpose stuff like R at school.
2022-12-28 18:03:41 <KipIngram   > decay: What do you mean by "bundle concept"?
2022-12-28 18:04:44 <decay       > KipIngram: multiple opcodes stored in a word.
2022-12-28 18:04:53 <KipIngram   > Oh, ok.
2022-12-28 18:06:26 <decay       > in crc's interpreter above, he assumes a 32 bit int and extracts the opcodes byte by byte.
2022-12-28 18:08:21 <decay       > you could shortcut the body of the interpreter by comparing the whole word to a list of known "bundles"/sub-programs.
2022-12-28 18:08:49 <decay       > and falling back to manual extraction/execution if you don't recognize any.
2022-12-28 18:09:03 <veltas      > Not sure that would even be faster
2022-12-28 18:09:25 <veltas      > Also you do know the VM is under 200 lines
2022-12-28 18:09:28 <decay       > sure it would. it'd just be a switch that dives into another switch.
2022-12-28 18:09:35 <decay       > by default.
2022-12-28 18:10:18 <veltas      > It's not really worth it if it makes the VM more complicated, I think its simplicity is highly valuable
2022-12-28 18:11:23 <decay       > it won't make it more complicated, you already have the whole bundle available in `process_bundle`. just do `switch(opcode){case <subprogram1>: ... break; case <subprogram2>: ... break; default: <process the opcodes individually>; }`
2022-12-28 18:12:04 <crc         > arland tells me having the vm recognize & shortcut at least some bundles is faster, at least under the python implementation. I think he's still profiling things to see which specific ones actually help there.
2022-12-28 18:12:43 <decay       > multi-op operations like "load operands from memory, do op, then store" would benefit.
2022-12-28 18:14:36 <vms14       > hmm I have some sort of noecho echo and cbreak
2022-12-28 18:15:07 <vms14       > I assume ctrl and alt key numbers that I receive need to be masked with something xD
2022-12-28 18:15:20 <KipIngram   > Yes, I see what you mean.
2022-12-28 18:15:42 <vms14       > [ r cbreak get.char ord .s recurse ] I have this loop so it prints the numeric value of a key
2022-12-28 18:15:50 <vms14       > still cbreak could go outside xD
2022-12-28 18:15:58 <vms14       > what I see also is esc is 27
2022-12-28 18:16:13 <vms14       > but the arrow keys seem to send 3 keys
2022-12-28 18:16:21 <vms14       > which the first is 27
2022-12-28 18:16:34 <vms14       > [27] [91] [65]
2022-12-28 18:16:55 <vms14       > oh.. they're sending esc [ A
2022-12-28 18:17:18 <vms14       > the same you give to the terminal to move the cursor
2022-12-28 18:19:18 <vms14       > still it's sad I have to peek to see if it's esc or an arrow key
2022-12-28 18:19:48 <KipIngram   > Of course, anywhere such a bundle would help, you could recognize that yourself, use the assembler to write a word that did those operations, and just call that word.
2022-12-28 18:20:14 <KipIngram   > So it wouldn't really add anything you couldn't otherwise do - it would just make the compiler more complex.
2022-12-28 18:20:56 <decay       > the compiler isn't involved with that, it'd be the interpreter that's responsible for detecting those patterns in the instruction stream.
2022-12-28 18:20:57 <KipIngram   > Basically, you'd be creating a "synonym" for the op bundle that was of a form your system could already process without change.
2022-12-28 18:21:08 <decay       > without the overhead of the call.
2022-12-28 18:21:31 <KipIngram   > Well, it would still have to somehow call the code that implemented the sequence, right?
2022-12-28 18:21:55 <KipIngram   > Or would it just be inline?
2022-12-28 18:22:01 <KipIngram   > Code threaded system?
2022-12-28 18:22:03 <decay       > inline to the inner interpreter loop.
2022-12-28 18:22:59 <KipIngram   > So bear with me.  Say you have words A, B, and (words you might type into your code to be interpreted), and say they do machine code segments a, b, c.
2022-12-28 18:23:17 <KipIngram   > If you recognized that as a bundle, somewhere you'd have to have a code segment abc, wouldn't you?
2022-12-28 18:23:34 <KipIngram   > Where does that segment come from in the first place?
2022-12-28 18:25:01 <decay       > the assumption is that your system (crc's interpreter) is word-addressible, so your instruction pointer falls along word boundaries. means that all of your code is packed into word-sized bundles. so if you had an assembler for that platform, and all of your instructions are byte-sized, you can pack those instructions into a single word.
2022-12-28 18:25:23 <veltas      > I love it when people find out how complicated escapes in input are
2022-12-28 18:25:30 <KipIngram   > Sure.
2022-12-28 18:25:36 <veltas      > "Why does vim hang for seconds on end when I press this button?"
2022-12-28 18:25:46 <decay       > because your system is word-addressible, and deals with words in general, you can compare the contents of memory at the instruction pointer with a set of known constants to recognize sequences of opcodes that are common.
2022-12-28 18:25:55 <veltas      > "Oh they're waiting for the escape sequence timeout"
2022-12-28 18:26:03 <KipIngram   > I guess when I think of "the interpreter," I think of something that is parsing your input and based upon it is calling pre-existing bits of code, to execute those operations.
2022-12-28 18:26:19 <decay       > no, this'd be underneath you, as a feature of the processor.
2022-12-28 18:26:25 <decay       > we're not talking forth, we're talking a VM.
2022-12-28 18:26:35 <decay       > the forth goes on top of the VM.
2022-12-28 18:27:20 <decay       > I actually wonder how padding works with this scheme. obviously not all programs fall into word-addressible lengths.
2022-12-28 18:27:31 <KipIngram   > I think in my system this is what would happen anyway - if I type a sequence of five words that correspond to machine instructions, starting on a cell boundary, that's exactly what it will do - it will compile those five instructions one after another and they will wind up packed into a word.
2022-12-28 18:27:39 <KipIngram   > Well, when I *compile*, that is.
2022-12-28 18:27:47 <decay       > right. same goes here.
2022-12-28 18:27:48 <KipIngram   > The *interpreter* will still execute them one at a time.
2022-12-28 18:28:03 <crc         > ls
2022-12-28 18:28:14 <KipIngram   > But we don't expect the interpreter to give maximum performance.
2022-12-28 18:28:50 <KipIngram   > You're talking about looking at a sequence of words, and if a whole sequence of them are machine instructions, have a table of common machine instruction sequences we could execute/
2022-12-28 18:29:01 <decay       > the VM in this case can handle single operations that are spread over multiple opcodes. "load op store" and "load load op store" are some examples of common operations.
2022-12-28 18:29:14 <KipIngram   > It would parse out all of them and then execute the whole set in one shot?
2022-12-28 18:29:19 <decay       > no.
2022-12-28 18:29:20 <decay       > http://fossils.retroforth.org:8000/ilo/file?ci=trunk&name=ilo.c&ln=166
2022-12-28 18:29:22 <decay       > this line.
2022-12-28 18:29:24 <decay       > underneath this line.
2022-12-28 18:29:48 <decay       > have a switch on opcode. each case is a constant representing a sequence of opcodes of a known subprogram.
2022-12-28 18:30:07 <decay       > common opcode sequences get executed faster because they don't have to go through inner switch one at a time.
2022-12-28 18:30:14 <decay       > nothing to do with forth.
2022-12-28 18:30:18 <KipIngram   > How do you decide when to do that?
2022-12-28 18:30:40 <KipIngram   > The interpreter will have to recognize a whole sequence of words, won't it?
2022-12-28 18:31:06 <decay       > you'd only be optimizing for common sequences of opcodes.
2022-12-28 18:31:13 <crc         >  in this case, process_bundle() would recognize a cell as matching a particular combination and running a function that does the various steps
2022-12-28 18:31:24 <KipIngram   > Sure.  But you'd have to LOOK for those sequences when scanning the source.
2022-12-28 18:31:32 <decay       > you don't scan the source..?
2022-12-28 18:31:39 <KipIngram   > You wouldn't be doing the normal space-delimited word matching anymore?
2022-12-28 18:31:43 <decay       > this is not forth!
2022-12-28 18:31:48 <decay       > it's just a bytecode VM!
2022-12-28 18:31:51 <decay       > there is no parsing!
2022-12-28 18:32:02 <decay       > there are four lights! wait, wrong context.
2022-12-28 18:32:06 <KipIngram   > Ok, I think I see now.
2022-12-28 18:32:16 <crc         > e.g., for a `lit / call` sequence, it could bypass copying the address to the data stack before doing the branch
2022-12-28 18:32:43 <KipIngram   > I could see maybe using a tree structure; you'd look at the first opcode and see if you had a tree root for it.  If not, process it.
2022-12-28 18:33:13 <KipIngram   > If yes, look at the next opcode and see if you have a child of that root for that byte.  if not, execute the root and promote the child to root.
2022-12-28 18:33:15 <KipIngram   > Etc.
2022-12-28 18:33:33 <decay       > exploit the fact that you can extract and compare constants without having to check individual bytes.
2022-12-28 18:33:41 <KipIngram   > You could go as far down as you kept matching, and whenever you rran out, you'd execute the longest sequence you'd found and promote the mismatch to root.
2022-12-28 18:33:47 <KipIngram   > That might actually be rather efficient.
2022-12-28 18:34:43 <KipIngram   > You'd look ahead until you picked up a byte for which you had no leaf availble.
2022-12-28 18:35:07 <crc         > in http://fossils.retroforth.org:8000/ilo/file?ci=tip&name=vm%2Filo.py&ln=218 (python), arland implements a direct handler for the 'lit/call/nop/nop' bundle
2022-12-28 18:35:33 <decay       > exactly like that.
2022-12-28 18:35:43 <crc         > bypassing the actual split/execute of the actual instructions
2022-12-28 18:36:06 <crc         > this makes the vm faster, but longer & more complex
2022-12-28 18:36:41 <crc         > (he does this in the python, as python is slow enough for things like this to make a noticable difference)
2022-12-28 18:36:57 <KipIngram   > Right.  I get it now.  It just took a couple of pokes to get me from "Forth interpreter" to "bytecode interpreter."  Now I understand why you would CARE.
2022-12-28 18:37:06 <decay       > hehe.
2022-12-28 18:37:15 <decay       > felt like I was speaking french for a moment while everybody else was speaking english.
2022-12-28 18:37:37 <KipIngram   > Well, I think I came in late and I was the odd man out.
2022-12-28 18:38:14 <veltas      > Yeah I was going to say, the fact it works in Python has no bearing on C
2022-12-28 18:38:15 <KipIngram   > Now, what I said holds to, though, right?  if you recognized that sequence yourself and defined a word for it, and used it, then instead of that bundle you'd have an address and you'd get the same performance benefit?
2022-12-28 18:38:51 <decay       > not really, because underneath that you'd still need to execute the opcodes one by one.
2022-12-28 18:38:52 <KipIngram   > Except that doesn't really work for lit/call/nop/nop, because you'd need to know in advance what the lit was.
2022-12-28 18:39:09 <decay       > (this is assuming you're building a forth on top of the bytecode VM).
2022-12-28 18:39:22 <KipIngram   > Ok.
2022-12-28 18:39:28 <decay       > (if you're building a native forth, yeah, it'd have the same perf. benefit.)
2022-12-28 18:39:48 <decay       > (same concept, different areas of use.)
2022-12-28 18:39:48 <veltas      > I can't imagine a situation I'd want to run a bytecode VM *in python* which is itself a slow interpreted language
2022-12-28 18:40:00 <decay       > veltas: maybe as a sandboxed language for a game.
2022-12-28 18:40:09 <veltas      > Well 'slow', 'medium' because bash exists
2022-12-28 18:40:41 <KipIngram   > Well, I implemented a printf functionality thing in my last Forth that used a bytecode interpreter.
2022-12-28 18:40:48 <veltas      > bash makes tcl look like assembler
2022-12-28 18:40:52 <KipIngram   > The format fields were basically "executed."
2022-12-28 18:46:20 <Zarutian_iPad> hmm? how does bash make tcl look like assembler? I understand how tcl works and have written code in it
2022-12-28 18:48:45 <veltas      > Zarutian_iPad: performance wise
2022-12-28 18:49:11 <veltas      > I was saying Python is slow, and then I corrected myself and said actually it's 'medium' because bash exists
2022-12-28 18:49:31 <veltas      > And performance-wise, bash makes tcl look like assembler
2022-12-28 18:50:44 <crc         > The python and lua implementations are the slow ones
2022-12-28 18:54:02 <veltas      > Have you tried luajit?
2022-12-28 18:55:31 <veltas      > The Lua implementation could be improved even in vanilla 5.4, you're using floating-point division where you want integer division for instance, and %256 instead of &0xFF etc
2022-12-28 18:55:54 <veltas      > New Lua has `//` for integer divide, and bitwise operators
2022-12-28 18:56:03 <veltas      > Luajit has library equivalents of these
2022-12-28 18:56:39 <crc         > I'm not very familiar with Lua, I'll look at luajit
2022-12-28 18:57:20 <veltas      > Well not sure if 0xFF is allowed in Lua but 255 is
2022-12-28 18:57:48 <veltas      > Lua's one of my favourite programming languages, not used it much in years though
2022-12-28 18:58:05 <KipIngram   > I considered the idea of an emulator for what I'm working on, but the goal there sure wouldn't be top performance.  Unpacking my six bit instructions would be a pain.
2022-12-28 18:58:15 <veltas      > It's my favourite 'scripting language' if we don't consider Forth a scripting language
2022-12-28 18:58:37 <KipIngram   > I'm unfamiliar with it - I'll also take a look.
2022-12-28 18:59:56 <veltas      > awk is my other favourite scripting language, and probably more up your alley
2022-12-28 19:00:55 <veltas      > awk is pretty much just a tiny scripting language with C's syntax and some cool builtin features, impractical for larger projects
2022-12-28 19:01:17 <veltas      > But it impacted every scripting language after it
2022-12-28 19:01:33 <KipIngram   > Hey.
2022-12-28 19:01:36 <KipIngram   > Heh, rather.
2022-12-28 19:01:40 <KipIngram   > From Wikipedia:
2022-12-28 19:01:42 <KipIngram   > As a result, the base language is light—the full reference interpreter is only about 247 kB compiled[4]—and easily adaptable to a broad range of applications.
2022-12-28 19:01:49 <KipIngram   > 247kB is "light"?
2022-12-28 19:01:58 <KipIngram   > The person who wrote that must be unfamiliar with Forth.
2022-12-28 19:02:03 <veltas      > It's gotten much bigger over the years
2022-12-28 19:02:09 <thrig       > compared to other scripting languages...
2022-12-28 19:02:17 <veltas      > I think that has been updated without serious consideration
2022-12-28 19:02:46 <KipIngram   > On the other hand, 247 kB IS light in the context of our current computers.
2022-12-28 19:02:52 <veltas      > Lua used to be reasonably small
2022-12-28 19:03:16 <veltas      > That's not even honest, I think the current interpreter is like 500KB or more
2022-12-28 19:03:42 <veltas      > If you build it statically, which is the only reasonable criteria since we don't really care about these sizes on desktop, only in embedded
2022-12-28 19:03:45 <thrig       > because people want integer support or Unicode or other such crazy things
2022-12-28 19:04:01 <KipIngram   > Oh, the Lua while structure is kind of nice - allowing a whole block of code for computing the condition.
2022-12-28 19:04:35 <veltas      > I hate Lua's syntax actually, it's my biggest issue with it
2022-12-28 19:04:43 <KipIngram   > Oh, wait - I misread what I was just speaking of.
2022-12-28 19:05:14 <veltas      > 1-based indexing, the ~= operator means != , and also bipolar "while" vs "until" ... I shouldn't have to negate a condition because I went from while to do-while
2022-12-28 19:05:29 <veltas      > "end end end end"
2022-12-28 19:05:43 <veltas      > But the semantics of Lua are really lovely
2022-12-28 19:07:53 <veltas      > The ugly truth is that JavaScript is not that far off of a Lua with better syntax. It's not quite as nice as Lua's model but it's on everyone's computers already and optimised by thousands of people who are paid to be there
2022-12-28 19:09:34 <thrig       > ... all you wanted was the scripting language but it came with Google's Gorilla And Forest Friends
2022-12-28 19:09:36 <decay       > JS is just a popular Lisp.
2022-12-28 19:10:59 <veltas      > I'm not sure how to think that other than it's a known thing Brendan Eich wanted to do a lisp and tried to apply lisp logic
2022-12-28 19:11:13 <decay       > that's where I was going. :)
2022-12-28 19:11:18 <veltas      > But it's really not like lisp at all, it's just yet another c-style scripting language
2022-12-28 19:11:24 <veltas      > There's nothing lispy about it at all
2022-12-28 19:11:33 <thrig       > somehow they managed to screw up LET and create a temporal dead zone in JS
2022-12-28 19:11:41 <decay       > "JS is just a popular Lisp" was a shitpost in the early aughts I think.
2022-12-28 19:12:05 <veltas      > Brendan obviously preferred old-school declarations
2022-12-28 19:12:09 <Zarutian_iPad> Lua? well as Lisp uses lists for everything, Lua uses tables for nearly everything
2022-12-28 19:12:10 <veltas      > I do too
2022-12-28 19:13:12 <veltas      > Which makes Lua far superior because lists suck
2022-12-28 19:13:38 <decay       > what's the difference. /s
2022-12-28 19:14:07 <veltas      > Lisp programmers laugh at C programmers for using linked lists occasionally and then it turns out everything in their language is infinitely slower than that somehow
2022-12-28 19:14:22 <veltas      > They have faster datastructures and nobody uses them because they're not as 'elegant'
2022-12-28 19:14:36 <thrig       > huh? I use structs and whatnot in lisp
2022-12-28 19:15:27 <veltas      > Why a high level language even has stuff like association lists that aren't tables is beyond me, they're everywhere in lisp code
2022-12-28 19:15:43 <decay       > what is a "table", exactly.
2022-12-28 19:15:52 <veltas      > A hash table
2022-12-28 19:15:53 <decay       > I thought it was just a nested associative array.
2022-12-28 19:15:55 <decay       > lol.
2022-12-28 19:16:07 <decay       > you'd really like JS then..
2022-12-28 19:16:19 <veltas      > Yeah I do compared to lisp lol
2022-12-28 19:18:10 <KipIngram   > Hash tables are great as long as you have memory to burn.
2022-12-28 19:18:11 <veltas      > It's not like when C++ programmers have to use std::unordered_map<std::string,Rec,std::my_hash> on every map with like 4 items when they could have used an array
2022-12-28 19:18:23 <KipIngram   > Just make it big enough that you have almost no collisions.
2022-12-28 19:20:19 <veltas      > There's a whole science to hash tables nobody appreciates, like did you know a pseudorandom hash is actually unoptimal? You can do way better if you actually understand your data
2022-12-28 19:20:48 <KipIngram   > Yeah, they're very "mathematical."
2022-12-28 19:22:09 <veltas      > If I store keys in range 4000 to 4010 by just having a size 11 array and subtracting 4000 from the index I've got a perfect spread, no holes. But I had to *think*, awful.
2022-12-28 19:23:04 <KipIngram   > Right - exactly right.  But it's not just "understanding" your data, is having nice data / controlling your data too.
2022-12-28 19:23:12 <KipIngram   > You couldn't do that with just any 11 random numbers.
2022-12-28 19:23:15 <KipIngram   > Not as easily.
2022-12-28 19:23:32 <KipIngram   > What you're really exploiting there is the structured organization of the data itself.
2022-12-28 19:23:45 <veltas      > If you always scrutinise and simplify requirements, it's quite often the case your keys aren't entirely random
2022-12-28 19:23:46 <decay       > yeah, there's not a general solution to it.
2022-12-28 19:24:06 <decay       > largely because your key space varies per problem.
2022-12-28 19:24:13 <KipIngram   > Yeah - you might not "often" be able to do as well as your example there, but you're exactly right - it's rarely "as bad as random."
2022-12-28 19:24:28 <KipIngram   > There's usually SOME information content in the structure of your data you can exploit.
2022-12-28 19:24:46 <KipIngram   > Which is why English text compresses by around 3:1, too.
2022-12-28 19:24:52 <KipIngram   > Same kind of idea.
2022-12-28 19:25:23 <KipIngram   > English isn't random.
2022-12-28 19:25:40 <veltas      > Say I have a 400TB array of characters and I want to sort the whole array into ASCII order do I use std::sort? Or do I use the O(1) counting sort algorithm?
2022-12-28 19:26:43 <veltas      > I wonder if the standard C++ library does counting sort on small types
2022-12-28 19:26:44 <KipIngram   > I think I'd just read through the data once and keep a character count table.  That is then a run-length encoded form of your sorted list.
2022-12-28 19:27:04 <veltas      > That's counting sort
2022-12-28 19:27:24 <veltas      > O(n), not O(1)
2022-12-28 19:27:25 <KipIngram   > Oh, ok.  Well, that would be the obvious way to solve that prolem.
2022-12-28 19:27:28 <KipIngram   > Right.
2022-12-28 19:27:29 <veltas      > What am I talking about lol
2022-12-28 19:27:29 <decay       > I'd go with that too. single pass through the data.
2022-12-28 19:28:09 <veltas      > It's a O(n) sorting algorithm with O(k) memory usage where k is the size of your sorted type's domain
2022-12-28 19:28:17 <KipIngram   > That works because you are sorting CHARACTERS, of which there is a modest number of such that your table is small.
2022-12-28 19:28:45 <veltas      > If I'm sorting a 400TB array of 32-bit numbers?
2022-12-28 19:30:05 <veltas      > Then counting sort is what I want still, O(n) and only use like 16GB working memory (less with some kind of smart compression scheme)
2022-12-28 19:30:49 <decay       > it'd be a 100TB element array.
2022-12-28 19:31:10 <decay       > or rather, a 100 tera-word array.
2022-12-28 19:31:28 <veltas      > The counting array would be like 16GB
2022-12-28 19:31:30 <decay       > that's 109,951,162,777,600 possible words.
2022-12-28 19:31:58 <veltas      > Or 32GB rather
2022-12-28 19:32:19 <veltas      > Because there are 4G values to track, need a 64-bit counter for each one
2022-12-28 19:32:41 <decay       > yeah. counting sort is still optimal.
2022-12-28 19:33:02 <veltas      > I wonder if people studying "big data" even know this trivial stuff, I would guess like half of them don't
2022-12-28 19:33:39 <decay       > I work at Amazon. there's quite a lot of these optimizations used in S3.
2022-12-28 19:33:54 <veltas      > That doesn't suprise me
2022-12-28 19:34:00 <decay       > but that's largely because the "big data" types don't care about stuff like this.
2022-12-28 19:34:20 <decay       > because they're not writing applications that care about it. they do care about data processing, just not about resource constraints.
2022-12-28 19:34:30 <decay       > funnel all of your data into something like an SQL database and you're good to go, man.
2022-12-28 19:34:31 <veltas      > I'd expect centralised infra to get it right because they're employing a lot of bright people who will know
2022-12-28 19:34:45 <decay       > I wouldn't call them bright. half them don't know what a trie is.
2022-12-28 19:34:50 <decay       > and the people that did left a while ago.
2022-12-28 19:34:57 <veltas      > I didn't say "most", I said "a lot"
2022-12-28 19:35:31 <decay       > I never said "most" either".
2022-12-28 19:36:39 <veltas      > I mean I'm not surprised half don't know what a trie is
2022-12-28 19:36:48 <veltas      > But there are enough people that know what they're doing
2022-12-28 19:37:02 <decay       > been here a while and I don't think that's the case.
2022-12-28 19:37:07 <Zarutian_iPad> decay: wait, what? they do not know what a trie is? lol
2022-12-28 19:37:27 <decay       > largely because there's few who last through the cycles of hire/dissolve for business teams.
2022-12-28 19:37:38 <decay       > Zarutian_iPad: oh yeah man.
2022-12-28 19:38:11 <MrMobius    > dont they weed people out by algorithms and other stuff you rote learn in undergrad?
2022-12-28 19:38:13 <decay       > I implemented one because I needed to store a bunch of tuples in memory that had some common prefixes (think RDF triples expanded into quads and quints). figured I'd save on memory in lambda.
2022-12-28 19:38:17 <MrMobius    > the study groups seem to be 100% that
2022-12-28 19:38:30 <KipIngram   > 24 GB?  4G possible words, with a 6-byte count for each one?
2022-12-28 19:38:42 <veltas      > decay: Yeah I suppose my main feeling is that 'at some point' there were enough people, maybe not anymore
2022-12-28 19:38:46 <decay       > MrMobius: that's the case with some teams.
2022-12-28 19:38:56 <decay       > veltas: it's kind of jarring how big the outflow has been.
2022-12-28 19:39:08 <thrig       > I was asked during the Amazon job interview to implement sort. I said I would use the library version and what would a system analyst be doing implementing sort?
2022-12-28 19:39:25 <decay       > nobody understands our Rete algorithm implementation for event matching anymore.
2022-12-28 19:39:34 <decay       > save for my buddy the SDE lead.
2022-12-28 19:40:06 <veltas      > The thing is, I don't know my algos. But I remember ones that seem useful, and if you tell me I can have a O(n) sorting algorithm then I remember stuff like that
2022-12-28 19:40:26 <veltas      > And that's because I actually care about performance and find it interesting
2022-12-28 19:40:27 <Zarutian_iPad> havent heard of that algorithm before
2022-12-28 19:40:43 <decay       > it's a useful if not complex one.
2022-12-28 19:40:57 <Zarutian_iPad> I just look some of them up in Knuth books when required
2022-12-28 19:41:13 <veltas      > I google it, don't have fancy books laying around
2022-12-28 19:41:20 <veltas      > But I'll go to a good old paper on it if I can find one
2022-12-28 19:41:24 <KipIngram   > Oh, I just looked up  Rete algorithm; that's a little like what I was talking about earlier for recognizing known sequences of opcodes.
2022-12-28 19:41:26 <veltas      > Old papers are the best
2022-12-28 19:41:26 <Zarutian_iPad> but I often do not recall the names of them just vaguely what they do
2022-12-28 19:41:41 <veltas      > Yeah I'm the same way Zarutian_iPad
2022-12-28 19:42:09 <KipIngram   > Yeah, I rely on the internet for that sort of "recollection."
2022-12-28 19:42:10 <Zarutian_iPad> probably because I never took CS univeristy courses
2022-12-28 19:42:18 <decay       > I usually don't keep any algorithms in my head at first recall. engineering things from the bottom up is more fun.
2022-12-28 19:42:48 <KipIngram   > decay: Indeed.  I feel like I know a fair bit about "a lot of things," but I do it by mostly remembering basic foundational principles and how they work together.
2022-12-28 19:43:00 <KipIngram   > I usually don't have total recall of every detail of a specialty.
2022-12-28 19:43:29 <veltas      > decay: You just have to think "where can I use this?" Nobody tells you when you learn red-black trees that you can write DOOM with that (or can you? whatever you need to balance a BSP)
2022-12-28 19:43:30 <KipIngram   > One of my daughters got irate with me because when I helped her with statistics I'd go down to ground probability theory principles.
2022-12-28 19:43:41 <KipIngram   > But I don't walk around remembering all those fancy stats methods.
2022-12-28 19:43:58 <KipIngram   > I work out the problem from basic probabiity theory.  Takes me longer, but I get the right answer just the same.
2022-12-28 19:44:01 <decay       > my brain is small so I can't keep a lot in my head.
2022-12-28 19:44:09 <KipIngram   > The stats stuff is a library of "labor saving shortcuts."
2022-12-28 19:44:27 <Zarutian_iPad> good for partot learning
2022-12-28 19:44:38 <KipIngram   > If I had to do that stuff every day, then I'd remember those.
2022-12-28 19:44:42 <Zarutian_iPad> parrot*
2022-12-28 19:45:11 <veltas      > I hate learning stuff by heart
2022-12-28 19:45:20 <KipIngram   > Me too - memorization is no fun.
2022-12-28 19:45:22 <veltas      > Has to be done sometimes but I definitely don't prefer it
2022-12-28 19:45:27 <KipIngram   > It's why I never proceeded beyond where I did with chess.
2022-12-28 19:45:48 <KipIngram   > I was pretty interested in it for a while, but I got to the point where the "next logical phase" of my development was to just "learn the standard openings."
2022-12-28 19:45:56 <KipIngram   > And, well, that was no fun at all.
2022-12-28 19:46:05 <KipIngram   > I really enjoyed the "principle based parts."
2022-12-28 19:46:11 <veltas      > I know one is called the "Queen's Gambit" :P
2022-12-28 19:46:21 <veltas      > standard opening
2022-12-28 19:46:24 <Zarutian_iPad> more usefull to be able to infer from smaller memorised knowledge base to what you need at that moment
2022-12-28 19:46:29 <KipIngram   > Yeah, and there are like dozens  hundreds once you're a couple of moves in.
2022-12-28 19:46:33 <veltas      > You have to do a lot of drugs for that one
2022-12-28 19:46:53 <KipIngram   > And if you make the smallest error - deviate from the standard path - an opponent who learned the openings better than you did will beat you, because he knows exactly how to exploit that.
2022-12-28 19:47:26 <KipIngram   > So in most of those games its a fair number of moves in before anyone does anything "original."
2022-12-28 19:47:28 <Zarutian_iPad> chess is too mechanistic for me
2022-12-28 19:47:30 <thrig       > or you con them into playing chess960
2022-12-28 19:47:37 <decay       > chess is boring.
2022-12-28 19:47:42 <veltas      > It really depends whether you can enjoy that
2022-12-28 19:48:10 <KipIngram   > Backgammon is nice.  It has an element of strategy to it - enough to make it fun.  But enough luck to allow things to go all sorts of ways, even when the players aren't exactly matched.
2022-12-28 19:48:28 <KipIngram   > Basic probability theory comes in really handy for backgammon.
2022-12-28 19:49:11 <veltas      > It's interesting when people dominate a game for years and years like Ronnie O'Sullivan
2022-12-28 19:50:26 <KipIngram   > Don't you figure it's a little like Mozart being great at music?  Every now and then a "savant" comes along in a field.  Someone that just has some hard to explain "special gift."
2022-12-28 19:50:59 <decay       > obsessives typically dominate their fields.
2022-12-28 19:51:11 <decay       > often to their detrement.
2022-12-28 19:51:25 <KipIngram   > Well, balance is a good thing to have in your life.
2022-12-28 19:51:46 <veltas      > Ronnie O'Sullivan seems extremely normal though
2022-12-28 19:52:10 <KipIngram   > I sometimes worry about these teenage Olympic superstars.  I mean, it's great they're so good at their activity, but... are they "living?"  Or just spending all their time doing that one thing?
2022-12-28 19:52:21 <KipIngram   > They're missing out on things too.
2022-12-28 19:52:51 <veltas      > If he really enjoys snooker and just plays it a lot and is really good at it does there have to be something wrong?
2022-12-28 19:52:58 <veltas      > And I'd feel the same way about olympics
2022-12-28 19:53:06 <veltas      > Better than what most kids do with their time
2022-12-28 19:53:59 <KipIngram   > Sure; I don't disagree.  I guess with kids my concern is tha tit's not really them making the decisions; that they're influenced by a coach or parents or whatever, who aren't necessarily motivated by the kid's best interests.
2022-12-28 19:54:18 <KipIngram   > But yeah - you're right; people should be free to choose to do things that way if they want to.
2022-12-28 19:54:55 <veltas      > I enjoy watching him intentionally ruin a maximum break because the prize is too low because he kept winning those pots years ago
2022-12-28 19:58:25 <veltas      > People thrive on competition I think
2022-12-28 19:58:40 <veltas      > There is a healthy attitude for it, and an unhealthy one
2022-12-28 19:58:45 <KipIngram   > Oh yeah, I think so too.
2022-12-28 19:58:50 <KipIngram   > Yeah, that too.
2022-12-28 19:59:07 <KipIngram   > Nothing wrong with enjoying victory.
2022-12-28 19:59:18 <KipIngram   > Nice if you can handle loosing without imploding too.
2022-12-28 19:59:33 <veltas      > Don't base your life on it but sure, enjoy pursuing that accomplishment, and get what you get. Only one person gets to 'win', but everyone can play honourably and with dignity
2022-12-28 20:00:00 <veltas      > And if you do win make sure to rub their faces in it
2022-12-28 20:00:15 <KipIngram   > Also, usually "whole contests" consist of many "micro events," and even if you don't come out on top at the end there can be plenty of moments to savor.
2022-12-28 20:00:39 <KipIngram   > I think the healthy part of it is enjoying being pushed to your best.
2022-12-28 20:01:41 <KipIngram   > And it's awfully fun now and then to watch a performance when an athlete or a team is just "in the zone," and they just play beyond themselves.
2022-12-28 20:02:41 <KipIngram   > My youngest daughter was born with some urinary tract defects, and she got surgery for that when she was around one year old.  The night after my wife and I were in the hospital with her; she was asleep and we were not going to find out until the next day how everything "really looked."
2022-12-28 20:02:46 <KipIngram   > So it was a tough evening.
2022-12-28 20:03:12 <veltas      > Don't think she'd appreciate you telling us that lol
2022-12-28 20:03:14 <KipIngram   > We found our alma mater (University of Texas at Austin) playing USC in the Rose Bowl on TV, for the national football championship.
2022-12-28 20:03:26 <KipIngram   > The UT quarterback that year was Vince Young.
2022-12-28 20:03:45 <KipIngram   > And in that game it was as though Vince had made a deal with the devil or something - he just couldn't fail.
2022-12-28 20:04:15 <KipIngram   > UT was well behind with a few minutes left, but they scored and then got a lucky interception, which brought Vince back onto the field.
2022-12-28 20:04:28 <KipIngram   > Somehow I just new the minute that happened we were going to win - that he would find a way.
2022-12-28 20:04:33 <KipIngram   > And he did.
2022-12-28 20:04:34 <veltas      > Is this related to your daughter?
2022-12-28 20:04:50 <KipIngram   > Just because it took our mind off of the worry for a few hours.
2022-12-28 20:04:59 <KipIngram   > Not completely, but it was "uplifting."
2022-12-28 20:04:59 <veltas      > Ah right
2022-12-28 20:05:11 <KipIngram   > The surgery turned out fine.
2022-12-28 20:05:17 <veltas      > Cool
2022-12-28 20:05:26 <veltas      > How old is she now?
2022-12-28 20:05:36 <KipIngram   > We wound up having to worry some more, because on her first check in a few weeks later the doctor was worried that things weren't shaping up as well as he wanted.
2022-12-28 20:05:45 <KipIngram   > he seemed more disappointed in himself than anything else.
2022-12-28 20:05:57 <KipIngram   > But when we went back for the 6-month checkup, everything looked great and he was delighted.
2022-12-28 20:06:06 <KipIngram   > Just took her a little longer to get up the curve, I guess.
2022-12-28 20:07:22 <KipIngram   > but yeah, my point was that it's not like my wife and I are footbal nuts or something.  Not just any old game would have distracted us like that.
2022-12-28 20:07:39 <KipIngram   > But it really felt like we were watching one of those special "in the zone" moments that you just don't see very often.
2022-12-28 20:10:18 <veltas      > Yeah
2022-12-28 20:10:23 <veltas      > How old is she now?
2022-12-28 20:13:15 <KipIngram   > She turned 18 in November.
2022-12-28 20:13:58 <KipIngram   > Starts college next fall.
2022-12-28 20:41:07 <KipIngram   > You know, I think these Xilinx block RAMs are just optimized for applications OTHER than processor design.  Basically, if during a clock cycle you want to access a particular address in a block RAM, you have to have that address presented to the block RAM at the end of the previous cycle.
2022-12-28 20:41:49 <KipIngram   > I can only have two address registers because there are two ports on the RAM - I can present one register to each one, and if the following cycle needs it, it's there.
2022-12-28 20:42:13 <KipIngram   > But the address needed cannot depend on the instruction about to be fetched or be computed by that instruction's operation.
2022-12-28 20:42:27 <KipIngram   > Not if you want single cycle instructions.
2022-12-28 20:43:00 <KipIngram   > Well, you could do the "half cycle" trick I mentioned a day or two ago, but that would mean a slower clock rate.
2022-12-28 20:46:34 <MrMobius    > how about pipelining?
2022-12-28 20:46:43 <MrMobius    > if you want single cycle
2022-12-28 20:48:25 <KipIngram   > Well, in my case I can get single cycle.
2022-12-28 20:48:55 <KipIngram   > Or at least I think I can; I'm still mulling it all over.
2022-12-28 20:49:03 <KipIngram   > Because there are two ports on the rams.
2022-12-28 20:50:40 <KipIngram   > As far as general purpose RAM access goes, I only address RAM with one of my two address registers.  During opcode cycles, I'll present one of those registers to each port, so if the instruction wants to do a read or a write the way will have been prepared.
2022-12-28 20:51:18 <KipIngram   > The block RAM that are used for stacks will be general purpose read only - the stack circuitry will own one port, and one of the address registers will own the other, so I can read through it.
2022-12-28 20:51:33 <KipIngram   > I'm following chuck's F21 design - all reads use the A registers, all writes use the B register.
2022-12-28 20:51:43 <KipIngram   > So stack RAMs will have A reg on port 2.
2022-12-28 20:52:08 <KipIngram   > The exception is the return stack, in which case the stack circuit needs port 2 as well in order to support double returns.
2022-12-28 20:52:36 <KipIngram   > That's where that config bit comes in - I can transfer port 2 control to A reg when I want to read from that RAM, and just be careful not to do any double returns in that mode.
2022-12-28 20:53:04 <KipIngram   > Should be pretty simple - flip the port 2 over to A reg, use a rep loop to read the entire return stack RAM into a buffer somewhere, and flip it back.
2022-12-28 20:53:48 <KipIngram   > The intstruction fetch circuitry also needs to be able to read from general RAM, but there is a non-opcode cycle once per instruction cell I can use to do that.
2022-12-28 20:54:16 <KipIngram   > When I'm about to go to that state, the instruction fetch ciruitry will determine the address on one of the ports.
2022-12-28 20:54:30 <KipIngram   > On opcode cycles the address register will get that port.
2022-12-28 20:54:33 <KipIngram   > It'll all work out.
2022-12-28 20:54:57 <KipIngram   > And it's really not as bad as that may have made it sound - that was kind of wordy, but the logic for it all is fairly simple.
2022-12-28 20:55:44 <KipIngram   > I had thought about trying to pipeline instruction fetches, though, to eliminate that extra cycle per cell during which no opcodes get executed.  But because of what I just outlined that won't be possible.
2022-12-28 20:55:53 <KipIngram   > That's the only time the instruction circuitry can get at RAM.
2022-12-28 20:56:42 <KipIngram   > I am still considering that fourth mode for those two extra cell bits, though - the one that will let me have two 15-bit relative calls in a cell, instead of one 30-bit call.
2022-12-28 20:56:54 <KipIngram   > I'm just enamored of what that would do for my code density.
2022-12-28 20:58:04 <KipIngram   > Basically if the instruction circuitry sees that bit pattern, it will expand the cell into two full 32-bit, single-call cells before passing them on to op_control.
2022-12-28 20:58:20 <KipIngram   > Well, those don't get passed to op_control.  Before passing them to the logic I've already designed.
2022-12-28 20:59:42 <KipIngram   > May add that later, though.
2022-12-28 21:00:32 <KipIngram   > Pipelining, though - it would help me predict how to address the RAMs in upcoming cycles, but I'd have to work it out in detail to see if I'd be able to predict PERFECTLY.
2022-12-28 21:00:45 <KipIngram   > conditionals and stuff might make it hard.
2022-12-28 21:04:08 <KipIngram   > that's likely the way I'd have to go if the rams only had one port, but otherwise worked the way they work.
2022-12-28 21:04:31 <KipIngram   > Say I had a rep loop that began with a RAM read, and the first opcode after the rep loop was a RAM write.
2022-12-28 21:05:03 <KipIngram   > When I'm in the rep cycle, if the loop is going to continue, then I'd want to present A reg to the RAM, but if it was going to finish, I'd want to present B reg.
2022-12-28 21:05:13 <KipIngram   > So all that kind of stuff would have to get worked out.
2022-12-28 21:05:43 <KipIngram   > I'd have to wire in a lot of knowledge about how the whole system worked.
2022-12-28 21:06:02 <KipIngram   > I mean, I guess it's exactly the path that the Intel guys went down over the years.
2022-12-28 21:06:07 <KipIngram   > A baby version of it.
2022-12-28 21:07:38 <KipIngram   > It's a little similar to what I just described - in that I have to be able to recognize when I'm ABOUT to go to the state that fetches an instruction cell, so that I can set up to give that logic RAM access.
2022-12-28 23:01:57 <KipIngram   > Wow.  I was thinking about how high fanout can be in Xilinx FPGAs.  I did a quick search and found one claim (just by someone who's professing to know - no "credentials" behind him that I'm aware of) that "timing failures are not usually caused by fanout for fanouts less than 1000."
2022-12-28 23:02:14 <KipIngram   > That's rather a higher number than I was expecting - that's actually pretty encouraging.
2022-12-28 23:02:40 <KipIngram   > I was worried that even a few dozen -ish might start to cause problems.
2022-12-28 23:04:01 <KipIngram   > I'm mainly concerned about it on block ram address and data inputs, since there are 135 block RAMs in the thing and I'd like to use pretty much all of them (unless I decide to put in multiple processors, in which case I'll split them).
2022-12-28 23:12:37 <KipIngram   > So basically I plan to send the low order bits of the "final address selection" (be it IP, A addr, or B addr) to ALL of the block RAMs.  There will be a few exceptions, for the stack rams and so on, but otherwise, yeah - all of the get that routed to them.
2022-12-28 23:13:27 <KipIngram   > The higher order bits will go through some logic that produces enable signals for each individual block RAM.