2022-05-04 04:25:05 <veltas      > MrMobius: "i thought about keeping the last few words in ram before writing any to the dictionary to do some peepholing"
2022-05-04 04:25:25 <veltas      > My plan is to keep the entire def separate to what's actually compiled
2022-05-04 04:25:49 <veltas      > I'm going to have pretty much an old-fasioned indirect threaded word, or tokenised word, alongside the compiled result
2022-05-04 04:26:07 <veltas      > Rather that gets 'compiled' first and then at `;` it actually generates machine code
2022-05-04 04:26:41 <veltas      > And the advantage is for simpler words that can be inlined I can inline the tokens straight into the token representation for more peep-holing
2022-05-04 04:27:57 <veltas      > It sounds 'heavy' but the right representation would be quite small, especially if I'm doing constant folding in advance of writing the tokens
2022-05-04 08:43:02 <KipIngram   > That sounds like it could give a nice "cost-benefit" payoff.
2022-05-04 08:44:26 <KipIngram   > So, would your regular definitions and your code go in different memory regions?
2022-05-04 08:50:29 <veltas      > If code is separate then yes
2022-05-04 08:51:23 <veltas      > So for me then yes, machine code will go in an executable area, the indirect threaded code will go in data area
2022-05-04 08:53:06 <veltas      > I aim to keep machine code separate because of the performance penalty of writing to an executable cache line (can cause instruction cache line invalidate on x86)
2022-05-04 08:53:25 <veltas      > Specifically the concern is a worst-case scenario may arise where you've got a hot variable next to the code that uses it
2022-05-04 08:53:43 <veltas      > So I'm avoiding that possibility, it's not something the programmer should have to worry about
2022-05-04 09:04:07 <KipIngram   > Good - sounds write.
2022-05-04 09:04:10 <KipIngram   > Ugh.
2022-05-04 09:04:12 <KipIngram   > Right.
2022-05-04 09:06:03 <KipIngram   > So, that's something I've wondered about re: the x86.  I know it has various levels of cache, with L0 being the fastest.  But does the cache management differentiate between code and data, or does it bring either into the L0 cache?
2022-05-04 09:06:25 <KipIngram   > I.e., is there actually an INSTRUCTION cache, or is it just a cache?
2022-05-04 09:07:20 <Zarutian_HTC> KipIngram: afaict x86 is now usually implemented as a modified Harward architecture
2022-05-04 09:07:20 <KipIngram   > Matters in my case because an *instruction* cache wouldn't get any of my "Forth" code, because it all looks like data to the processor.
2022-05-04 09:07:50 <KipIngram   > Primitves are actual code - definitions are "data."
2022-05-04 09:07:56 <KipIngram   > But for Forth they're code.
2022-05-04 09:08:14 <Zarutian_HTC> meaning the caches nearest a cpu core are split into i-cache and d-cache
2022-05-04 09:08:41 <KipIngram   > Ok.
2022-05-04 09:08:51 <Zarutian_HTC> instructions cache and data cache
2022-05-04 09:09:55 <Zarutian_HTC> recall my musing on implementing Forth VMs via SIMD, in that implementation the whole shebang is mostly data
2022-05-04 09:10:30 <KipIngram   > Right.  In direct or indirect threading, there's relatively little actual code.
2022-05-04 09:10:30 <Zarutian_HTC> primitives would be implemented in that SIMD loop
2022-05-04 09:12:04 <KipIngram   > That's one of the reasons I was wishing the other day that Linux offered a way to gain exclusivity to a core.  That way other threads wouldn't be constantly mashing your cache content.
2022-05-04 09:12:20 <KipIngram   > Caches are big enough these days that an entire Forth system can fit in them.
2022-05-04 09:12:39 <KipIngram   > Get a core, run a little bit to bring everything into the cache, and then just scream.
2022-05-04 09:13:02 <Zarutian_HTC> instead of having addresses of native code of primitives I prefer to allocate last few bits of an cell to primitive selector iff the other bits are zero
2022-05-04 09:14:00 <Zarutian_HTC> if the other bits of the cell arent zero then it is a Forth call to that address
2022-05-04 09:14:02 <KipIngram   > Yeah, when I've mused over hardware / FPGA based Forth I've usually used a packed opcode approach, with one bit indicating either "address" or "set of opcodes."
2022-05-04 09:14:36 <KipIngram   > Works nice in 16-bits; it's either a 15-bit address or three opcodes.
2022-05-04 09:15:00 <Zarutian_HTC> why? well it makes that Forth ultra portable
2022-05-04 09:15:06 <KipIngram   > That's the main reason it looked my fetch unit could pull out ahead of the execute unit, since once it found opcodes it got 'em three at a pop.
2022-05-04 09:15:44 <KipIngram   > I've never tried those ideas on a software implementation, though.
2022-05-04 09:15:57 <KipIngram   > Mine have all been pretty traditional at the guts level.
2022-05-04 09:16:28 <Zarutian_HTC> I been mulling over a BitGrid block addition to my fcpu16 design
2022-05-04 09:17:07 <KipIngram   > :-)
2022-05-04 09:17:52 <KipIngram   > I need to think more about that.  Once I noticed how similar it is to a "sea of gates" it's been hard for me to get out of that model.  I imagine there are other clever ways of using it, though.
2022-05-04 09:19:07 <Zarutian_HTC> well, I wrote quite a few moons ago an .c impl of fcpu32 which consisted of the forth image in a statically allocated and initialized array and a loop switch construct in the main func
2022-05-04 09:19:53 <Zarutian_HTC> it ran fast enough
2022-05-04 09:20:40 <Zarutian_HTC> and I was delighted to see that the c compiler emitted a jump table
2022-05-04 09:21:48 <KipIngram   > Speaking of the C compiler, I was really intrigued by the way those Mill CPU guys use the standard C++ compiler as an element of their synthesis toolchain.
2022-05-04 09:22:15 <KipIngram   > I want to look more into that - I bet there are a lot of interesting ways it could be leveraged.
2022-05-04 09:23:00 <Zarutian_HTC> KipIngram: I look at BitGrid as an bit level systolic array, and as asynchronus cellular automata, and as like the old AVR mini fpga I found
2022-05-04 09:23:15 <KipIngram   > Apparently they do the lion's share of the creation of a new family member using a chain of open source tools, then "hardware guys" step in for the last phases of placing and routing and so on.
2022-05-04 09:25:01 <Zarutian_HTC> as I understand how the Mill folks do it is that they use C++ as macro assembler and verilog which when compile gives an program that when is run produces the real verilog vhdl and such files
2022-05-04 09:25:22 <KipIngram   > Right; it is something like that.
2022-05-04 09:26:44 <Zarutian_HTC> then these verilog vhdl files get translated into register to register nets, then into gate nets
2022-05-04 09:28:30 <Zarutian_HTC> then or concurrently route and place tools plus manifacturers ruleset checks and cell libs come in
2022-05-04 09:29:02 <KipIngram   > Yes.
2022-05-04 09:29:20 <Zarutian_HTC> the latter changes usually with every manifacturing-node/min-feature-size
2022-05-04 09:29:30 <KipIngram   > They start more or less with a list of "features" the family member should have.
2022-05-04 09:31:45 <Zarutian_HTC> the idea I have on how to integrate a BitGrid block into fcpu16 is to have one side connected to TOS, another to NOS, and the other two sides are still tbd
2022-05-04 09:32:22 <KipIngram   > Oh, that's slick.  Yeah.
2022-05-04 09:33:36 <Zarutian_HTC> and mapping the BitGrid config space into the address space of that fcpu16
2022-05-04 09:34:40 <Zarutian_HTC> then just have an function selection prim/instr to select the output from the BitGrid
2022-05-04 09:35:43 <Zarutian_HTC> that way I basically have an way to have redefinable function unit
2022-05-04 09:36:09 <KipIngram   > Yes - I like it.
2022-05-04 09:37:05 <Zarutian_HTC> I recon that instead of having just 16 primitives, I can go up to 32 or 64
2022-05-04 09:37:42 <KipIngram   > That FPGA Forth I tinkered with had 32.
2022-05-04 09:38:01 <KipIngram   > 5 bits, three packed - those numbers worked well together.
2022-05-04 09:38:26 <Zarutian_HTC> one primitive to say, "I want BitGrid TOS side output be written to TOS register"
2022-05-04 09:39:18 <Zarutian_HTC> one to say "I want BitGrid NOS side to written to TOS"
2022-05-04 09:39:51 <Zarutian_HTC> and one another to say for both
2022-05-04 09:41:06 <Zarutian_HTC> one idea for the other sides of that BitGrid block is memory port to same memory as the fcpu16 uses
2022-05-04 09:42:23 <Zarutian_HTC> another idea to use part of one side for small i/o and interrupt line into the fcpu16
2022-05-04 09:44:27 <Zarutian_HTC> I am still sceptical of packing three primitives to a cell as it complicates the fetch-execute a bit
2022-05-04 09:44:54 <KipIngram   > Remember I was working with hardware.
2022-05-04 09:45:02 <KipIngram   > It's a lot easier to deal with there.
2022-05-04 09:45:45 <KipIngram   > I had a fifo between my fetch and execute units anyway - that fifo was just 15 bits in, 5 bits at a time out.
2022-05-04 09:45:46 <Zarutian_HTC> microcoded or hardwired instruction handling?
2022-05-04 09:46:01 <KipIngram   > Hardwired - gates for everything.
2022-05-04 09:46:03 <Zarutian_HTC> oh, I see
2022-05-04 09:47:42 <Zarutian_HTC> I am using basically a bit modified ROM logic as the main sequencer and instruction decode and execution
2022-05-04 09:48:05 <Zarutian_HTC> in the fcpu16 logisim evolution design
2022-05-04 09:48:17 <KipIngram   > Cool - I've never done a microcoded design of any kind.
2022-05-04 09:48:54 <Zarutian_HTC> have done ROM logic though?
2022-05-04 09:49:02 <Zarutian_HTC> have you*
2022-05-04 09:49:18 <KipIngram   > Mine had a side pipe that opcodes could be parallel routed into for "micro loops."  It just looped over the opcodes - didn't have to fetch them again.
2022-05-04 09:49:56 <KipIngram   > No, not per se.  I've worked primarily with gates, registers, and so on.
2022-05-04 09:51:50 <Zarutian_HTC> it is really simple: you have one register whose output feeds into some of the address lines of a rom, the other address lines are inputs. Then you feed some of the data lines of the rom into the register and the rest is outputs
2022-05-04 09:53:43 <KipIngram   > That side pipe was a little bit like the Mill "belt."  It was just a short pipe of already executed opcodes, and if you didn't use them they "fell off" the end.
2022-05-04 09:55:51 <KipIngram   > The Mill pipe is just for data, though - I think.
2022-05-04 09:56:15 <Zarutian_HTC> one application of ROM logic I saw in an old logic&computing book used a punched card for the ROM
2022-05-04 09:56:21 <KipIngram   > Its main purpose seemed to be to eliminate the need for register renaming and providing an "immutable" source of recent results.
2022-05-04 09:57:07 <KipIngram   > Some of those early machines are pretty cool.  Some of the earliest "programmed" work was in the textile industry, where the "program" controlled the weaving pattern.
2022-05-04 09:57:34 <KipIngram   > Wasn't "cards," but it was the same kind of idea.
2022-05-04 09:59:07 <Zarutian_HTC> the thing used a bunch of diodes. The select lines were rows with them on one side and the columns on the other side of the clamp were the card went in
2022-05-04 10:00:03 <KipIngram   > I suppose it just made through connections where there were holes?
2022-05-04 10:00:21 <Zarutian_HTC> the application? numpad lock in two parts that needed the code changed every week
2022-05-04 10:00:30 <Zarutian_HTC> yebb
2022-05-04 10:02:16 <Zarutian_HTC> and it had two codes, one for office hours and one for non office hours
2022-05-04 10:05:34 <Zarutian_HTC> and on what was this numpad lock on? a supply room
2022-05-04 10:08:58 <KipIngram   > Crown jewels.  :-)
2022-05-04 10:09:08 <KipIngram   > Can't let people steal pencils.
2022-05-04 10:10:14 <Zarutian_HTC> no, just a department that got sick of other departments niking their office supplies too much
2022-05-04 10:11:04 <KipIngram   > Well, little things like that can become damn annoying.
2022-05-04 10:11:18 <Zarutian_HTC> hence the weekly code change because it invariably got out but it took a bit more than a week to spread
2022-05-04 10:11:29 <KipIngram   > Right.
2022-05-04 10:11:38 <KipIngram   > Reasonable solution.
2022-05-04 10:12:20 <Zarutian_HTC> it was purely 'home made' solution
2022-05-04 10:49:10 <KipIngram   > I said I thought in terms of gates on that FPGA design.  That's not quite true.  I did - when I was figuring out functionality I was thinking "gates."  But what I actually did was think in terms of Xilinx six-input LUT terms - my goal was to have only two levels of combinational LUTs between register outputs and register inputs, so I'd be able to use the fastest possible clock.
2022-05-04 10:49:24 <KipIngram   > I was able to do that, including the decode and execution of all of those 5-bit opcodes.
2022-05-04 10:50:03 <KipIngram   > That did mean the opcode-to-operation assignment wasn't in any way "arbitrary" there was some thought behind it, to enable two-level decode.
2022-05-04 10:50:25 <KipIngram   > Somewhere upstairs there's a notebook with that opcode assignment in it.
2022-05-04 10:50:48 <KipIngram   > But it wasn't totally AND/OR/NOT gate thinking - it was "What can a LUT do?"
2022-05-04 10:51:15 <KipIngram   > I believe each LUT provided four arbitrary functions of six inputs.
2022-05-04 10:51:37 <KipIngram   > May have been two instead of four - can't remember for sure.
2022-05-04 10:51:49 <KipIngram   > But there were six inputs in that Xilinx family (Spartan).
2022-05-04 10:53:25 <KipIngram   > It used hardware data and return stacks - just stacks of registers.  Which would have been terrible for power, since every register would change whenever an item entered the stack, and all but one when an item leaves.
2022-05-04 11:04:52 <Zarutian_HTC> I just used normal memories for the stacks (block mems in Spartan 6) and drove their addresses with up down counter registers
2022-05-04 11:04:55 <Zarutian_HTC> bbl
2022-05-04 12:14:57 <Zarutian_HTC> https://gist.github.com/zarutian/0833e83a219ac6ca94e49166f571dd21
2022-05-04 13:12:13 <lispmacs[work]> hi all, I was just wondering if anybody had heard of this new systems programming language, and if it might be relevant as a foundation for Forth running on bare hardware
2022-05-04 13:12:17 <lispmacs[work]> https://harelang.org/blog/2022-04-25-announcing-hare/
2022-05-04 13:13:09 <lispmacs[work]> like, implement the Forth primitives in Hare, and some forth words using the opengl bindings
2022-05-04 13:21:50 <lispmacs[work]> not really advocating for it, but just wondering, since Forth is certainly bootstrappable on bare hardware, which has been done alot, but then nobody ever gets around to writing the file system and graphics libraries and such
2022-05-04 13:43:41 <lagash      > And if nobody said it yet - may the FORTH be with you! :)
2022-05-04 13:57:52 <Zarutian_HTC> 
ACTION switches his terminal to aurobesh

2022-05-04 14:01:57 <Zarutian_HTC> lispmacs[work]: some this is hare brained idea!
2022-05-04 14:19:00 <Zarutian_HTC> say, I completely Oprahed that verb
2022-05-04 15:11:59 <lispmacs[work]> Zarutian_HTC: okay, for thank you your thoughts
2022-05-04 15:19:21 <KipIngram   > I do hope to eventually "get around" to writing a file system.  I've thought about it a good bit; hashed out some data structures and so on.
2022-05-04 16:09:08 <veltas      > KipIngram: I wrote a very simple filesystem at work, I might do something similar at home and open source it
2022-05-04 16:09:19 <veltas      > Hopefully not too similar that I could get in trouble lol
2022-05-04 16:09:30 <veltas      > Sucks when my good ideas come out at work :P
2022-05-04 16:10:11 <veltas      > lispmacs[work]: My opinion as I said on HN is if I wanted C with slightly more features I would have been working in a nice C++ subset years ago
2022-05-04 16:10:45 <veltas      > And there are a lot of C-replacement languages out there, this one doesn't have really compelling syntax
2022-05-04 16:11:00 <veltas      > IMO if you're doing a new C-replacement language today it should have less syntax, not more
2022-05-04 16:11:10 <veltas      > Like closer to B in appearance
2022-05-04 16:12:03 <eris[m]     > hare doesnt have anything compelling
2022-05-04 16:12:08 <veltas      > If anyone's interested in writing a C replacement you are welcome to pick my brains on this in detail, I have actually thought about it a lot
2022-05-04 16:12:26 <veltas      > I have some good ideas, probably some bad ideas, I'm not all critique though I can be constructive
2022-05-04 16:13:20 <veltas      > But practically speaking you will never win the market because C already exists and is frankly good enough for what it does, any C-replacement will always have this problem
2022-05-04 16:17:16 <lispmacs[work]> Last update on my Forth LCD driver project:
2022-05-04 16:17:18 <lispmacs[work]> https://portal.mozz.us/gemini/gem.librehacker.com/gemlog/tech/20220504-0.gmi?inline=1
2022-05-04 16:17:26 <lispmacs[work]> Mecrisp Forth + RP2040
2022-05-04 16:24:41 <KipIngram   > Hey, cool.
2022-05-04 16:26:04 <KipIngram   > Those eight customizable char codes - six is enough to draw boxes - the four corner chars, and the horizontal and vertical straight chars.
2022-05-04 16:26:15 <KipIngram   > Those chars are also available, though, via ansi sequences.
2022-05-04 16:26:26 <KipIngram   > And I'm sure via UTF-8 as well.
2022-05-04 16:27:34 <KipIngram   > I like how you've set that site up.
2022-05-04 16:27:40 <KipIngram   > Nice and orderly and clean.
2022-05-04 16:37:28 <lispmacs[work]> KipIngram: Thanks, that Web site is actually a proxy mirror of my Gemini site using gemtext pages, which are by nature simple and clean
2022-05-04 16:37:40 <remexre     > how do Forths that compile to native binaries handle e.g. VARIABLE foo : foo@ [ foo ] LITERAL @ ;
2022-05-04 16:38:51 <remexre     > binaries that aren't just unexec()s, I mean
2022-05-04 16:39:36 <veltas      > In my design the answer is ... it doesn't handle that
2022-05-04 16:39:54 <veltas      > And I think that's probably how other forths that compile handle it too
2022-05-04 16:40:24 <veltas      > So you are a bit more restricted in operation... which makes sense to me
2022-05-04 16:40:52 <remexre     > hm, okay
2022-05-04 16:47:36 <KipIngram   > Why can't that be compiled as a literal followed by a fetch?
2022-05-04 16:47:45 <KipIngram   > I must be missing something.
2022-05-04 16:47:52 <remexre     > the address might be different from inside the compiler vs in the final binary
2022-05-04 16:47:59 <veltas      > That's it
2022-05-04 16:48:24 <KipIngram   > Oh - I see.  I overlooked the "native" part.
2022-05-04 16:48:28 <KipIngram   > I get it.
2022-05-04 16:48:36 <veltas      > You can choose a non-relocatable binary and map fixed addresses but it's not portable
2022-05-04 16:51:09 <KipIngram   > Yeah, I see the difference.  I was just thinking in terms of "compiled in the system"  Compiled Forth def.
2022-05-04 16:51:42 <KipIngram   > But yeah - I see the problem.  The executable has to make it possible to map things to whereever it gets loaded - that can't be compiled as "just a literal."
2022-05-04 16:52:03 <eris[m]     > can simply disallow things like that
2022-05-04 16:52:12 <KipIngram   > Yes.
2022-05-04 16:52:30 <KipIngram   > Provide a way to declare variables - provide a way to work with literals.  The two don't HAVE to be interchangeable.
2022-05-04 16:52:57 <veltas      > Yes and by 'disallow' I mean it will crash when you run it
2022-05-04 16:53:10 <KipIngram   > To some extent that code in the example is deliberately obtuse.
2022-05-04 16:53:20 <KipIngram   > It's not really how you'd ever naturally do a variable reference.
2022-05-04 16:53:37 <veltas      > mark4's forths use fixed map addresses
2022-05-04 16:53:39 <KipIngram   > Though I imagine there are other cases that get at the same thing that might be reasonable seeming.
2022-05-04 16:54:00 <veltas      > Yeah an array of addresses would fail for instance
2022-05-04 16:54:07 <veltas      > That's less contrived
2022-05-04 16:54:33 <veltas      > But mark4's forth didn't run on my system! I had to change the map
2022-05-04 16:54:49 <KipIngram   > Yeah - that's basically what a jump table is.
2022-05-04 16:54:49 <veltas      > And there are not 'correct' addresses to try mapping to, so it does indeed have portability issues
2022-05-04 16:55:01 <KipIngram   > I guess you could have an "array of relocatble things" entity.
2022-05-04 16:55:12 <KipIngram   > But it couldn't be just a number array.
2022-05-04 16:55:16 <veltas      > Much like an ELF
2022-05-04 16:55:22 <KipIngram   > :-)  Right.
2022-05-04 16:55:50 <veltas      > You are going to have an array like that or whatever ELF does if you're compiling binaries, yes
2022-05-04 16:57:28 <KipIngram   > Apple's MACH0 exec format is particularly restrictive.
2022-05-04 16:57:51 <KipIngram   > It just insists that everything be relative to load point.
2022-05-04 16:58:00 <veltas      > Yeah I was going to say I would guess future OS's, ABI's will disallow fixed addresses entirely
2022-05-04 16:58:26 <veltas      > So really you want to figure out how to work with relative addressing
2022-05-04 16:58:51 <KipIngram   > That what my "rrBB" register holds - it's got the base address of the whole system.
2022-05-04 16:58:54 <remexre     > yeah, my ABI already does this b/c I only care about aarch64
2022-05-04 16:59:10 <remexre     > so I can do everything pc-relative
2022-05-04 16:59:11 <KipIngram   > Sorry - no.  It's the address at which the "text" section is loaded.
2022-05-04 16:59:23 <KipIngram   > That's the block code and definitions are in.
2022-05-04 16:59:46 <KipIngram   > The "data" section is pointed to by r14, which I call rrHB (head base).
2022-05-04 16:59:55 <KipIngram   > And everything is in one or the other.
2022-05-04 17:00:21 <KipIngram   > Consequently I'm really only able to have one thread run smoothly right now.
2022-05-04 17:00:37 <KipIngram   > I'm going to have to work in a way to know your own "base as a thread."
2022-05-04 17:00:57 <KipIngram   > If I want to have anything thread-specific other than the stacks.
2022-05-04 17:01:17 <veltas      > remexre: So in my head I want to document the word that adds a relative symbol, so you can make anything relative explicitly if it isn't something trivial like a variable
2022-05-04 17:01:19 <KipIngram   > So I've got to keep at least one register available for that.
2022-05-04 17:01:43 <KipIngram   > It'll probably wind up being rbx.
2022-05-04 17:01:46 <veltas      > I think any good builds-to-executable forth should document that word because you never know what won't work
2022-05-04 17:01:57 <eris[m]     > but like
2022-05-04 17:02:32 <eris[m]     > a builds to executable forth should be different entirely
2022-05-04 17:02:54 <remexre     > veltas: like a special version of LITERAL? yeah, that shouldn't be too hard in my design, since I only start making the binary after all the definitions I want to compile have been made
2022-05-04 17:02:56 <eris[m]     > why try and emulate the interface of a normal forth
2022-05-04 17:03:12 <veltas      > remexre: Yeah, for example
2022-05-04 17:03:47 <KipIngram   > eris: I don't  know - I could imagine wanting to write a word and test in in system, and then just say "make an exec."
2022-05-04 17:03:52 <veltas      > eris[m]: Do you mean it should be like a cross-forth?
2022-05-04 17:03:59 <KipIngram   > I'd want it to write out only the bits of the system that were needed for that exec.
2022-05-04 17:04:26 <veltas      > I think there are advantages either way, for what I care about it's better to keep the interpreter
2022-05-04 17:04:27 <KipIngram   > But maybe that is an entirely different thing - that follows the word around the dictionary and builds something totally different.
2022-05-04 17:04:53 <veltas      > I can't think of an app I wouldn't want the forth interpreter to be there "just in case" i.e. for debugging or advanced features
2022-05-04 17:05:33 <KipIngram   > The thing is, if your exec is going to offer command input, then it's going to need an awful lot of the system.  I'm not sure I see what you gain in that case.
2022-05-04 17:05:51 <veltas      > "an awful lot of the system" yeah but forth is small
2022-05-04 17:06:02 <KipIngram   > But if it's a controller for a gadget or something - that could be pretty minimal.
2022-05-04 17:06:29 <veltas      > Yeah that's when you want a cross forth
2022-05-04 17:06:44 <KipIngram   > And it would probably be a lot easier to compile it from source (in which case yeah - it would be like a cross forth).
2022-05-04 17:06:55 <KipIngram   > Instead of trying to "convert" the already dictionary compiled thing.
2022-05-04 17:07:21 <veltas      > It really depends, right now I'm more focused on desktop forth (and also these days embedded is essentially as powerful as a small desktop from 20 years ago)
2022-05-04 17:07:31 <veltas      > Well some embedded socs are
2022-05-04 17:07:47 <veltas      > Some are still toasters
2022-05-04 17:07:51 <KipIngram   > I haven't thought much about general cross forth - themain thing I've thought about is meta-recompilation of the whole system.
2022-05-04 17:10:02 <KipIngram   > That's a goal for sure - to be able to have Forth source in my Forth system I can use to rebuild the whole thing.  Then I'll be able to cut the nasm umbilical.
2022-05-04 17:11:04 <KipIngram   > Then instead of using the OS to load my executable, I'll have a little program I run that loads an image out of my blk.dat file and hands control to it.
2022-05-04 17:11:40 <KipIngram   > Give the little program the block # to find the image at.
2022-05-04 17:11:50 <veltas      > I don't mind nasm but yeah it's compelling to be able to go 100% Forth
2022-05-04 17:11:52 <KipIngram   > Have a golden image in there too, for when I stub my toe.
2022-05-04 17:12:04 <veltas      > Definitely not a priority IMO
2022-05-04 17:12:11 <KipIngram   > I'm actually quite happy with nasm, but this just seems like the logical path to me.
2022-05-04 22:59:25 <vms14       > I've implemented colon words as strings with a pointer and the return stack is one array of those strings
2022-05-04 22:59:34 <vms14       > it's weird, but I think it can work
2022-05-04 22:59:47 <vms14       > https://termbin.com/xmpya
2022-05-04 23:20:06 <KipIngram   > Hi vms14
2022-05-04 23:21:31 <KipIngram   > What's the pointer in the string struct for?  Is that how you link words together?
2022-05-04 23:21:56 <KipIngram   > Or is it an offset into the word?
2022-05-04 23:22:01 <vms14       > the offset
2022-05-04 23:22:07 <KipIngram   > Into the string, I mean.
2022-05-04 23:22:09 <vms14       > read_word manipulates this pointer
2022-05-04 23:22:17 <KipIngram   > So, like a program counter for each one?
2022-05-04 23:22:22 <vms14       > well read_char does
2022-05-04 23:22:40 <vms14       > every time read_char is called it increments this pointer
2022-05-04 23:22:47 <vms14       > this is why it wants a reference
2022-05-04 23:22:50 <KipIngram   > I see.
2022-05-04 23:23:08 <vms14       > the thing is, a colon word can be represented as this
2022-05-04 23:23:25 <vms14       > even "recurse" can be implemented by just resetting this pointer xd
2022-05-04 23:25:12 <vms14       > if you run this example the output is "oh is my"
2022-05-04 23:25:22 <KipIngram   > Right.  We've noted a couple of times recently that you can do that in the text input buffer of most Forths.  There's a variable called >in that notes how far into the text you are.
2022-05-04 23:25:31 <KipIngram   > If you reset that to 0, it will start the line over.
2022-05-04 23:25:47 <KipIngram   > So, you better do it intelligently, with a way to stop, or you just hung your system.
2022-05-04 23:25:59 <KipIngram   > Unless you have a ctrl-c break or something like that.
2022-05-04 23:26:39 <KipIngram   > I've used it to time some of the internal activities, like searching the dictionary, converting numbers, and so on.
2022-05-04 23:27:02 <vms14       > I wonder if a colon word can really be represented as a string
2022-05-04 23:27:26 <KipIngram   > Well, a colon word is a string of addresses.
2022-05-04 23:27:39 <KipIngram   > If you have a way of interpreting bytes as primitives, then sure.
2022-05-04 23:28:36 <KipIngram   > Usually there's one central instruction pointer - not one per word.  but there's no particular reason why one per word wouldn't work.  Seems to me it would make your words non-reentrant, though.
2022-05-04 23:28:44 <vms14       > yes, I can have function pointers for primitives
2022-05-04 23:29:13 <KipIngram   > If you're in the middle of executing one, it can't be called again as part of that.  Except as a full recursion (from the tail end).
2022-05-04 23:29:32 <vms14       > I was thinking in reading the whole file or line and make this a colon word, then put that in the return stack
2022-05-04 23:30:05 <vms14       > the thing is, as is a string is raw code, so there is no need for literal
2022-05-04 23:30:21 <vms14       > the drawback is it means you'll be always "reading"
2022-05-04 23:30:43 <vms14       > but it makes the code serializable, at least the colon words
2022-05-04 23:34:30 <KipIngram   > Not sure what you are calling "raw code."  You don't mean machine code, do you?
2022-05-04 23:35:57 <vms14       > I mean being a colon word as a string you don't have any kind of bytecode, the colon word is actually raw code
2022-05-04 23:36:27 <vms14       > the compiler for example translates a 1 to a literal word
2022-05-04 23:37:18 <vms14       > in this case the compiler can have immediate words and alike, but when executing a colon word is the same as reading code from the input
2022-05-04 23:38:45 <vms14       > it's much slower, for example for every word listed in a colon word you'll have to search it in the dictionary
2022-05-04 23:39:19 <vms14       > this is done once when compiling, but in this case will be done every time you execute a word
2022-05-04 23:40:45 <KipIngram   > When Chuck first ever wrote about Forth, before it was really Forth, my take on his book was that he did something like that.  There didn't seem to be any compiled definitions at first.  It was more like what I think you just described - "executing" a word was more like subsitution a string for a symbol.
2022-05-04 23:40:54 <KipIngram   > And yes - slower.
2022-05-04 23:41:30 <vms14       > the book he didn't know why he wrote?
2022-05-04 23:48:11 <KipIngram   > Yeah.