2023-03-28 22:03:34 <vms14       > crc what benefits does a virtual machine provide versus just an interpreter/transpiler?
2023-03-28 22:03:53 <vms14       > more than a save/store state feature
2023-03-28 22:04:09 <vms14       > I see several, so I'm wondering
2023-03-28 22:04:34 <vms14       > for example the fact that the vm implementation is independent of syntax, it's mainly just a bytecode interpreter
2023-03-28 22:04:47 <vms14       > this means languages can be made on top of the vm
2023-03-28 22:05:04 <vms14       > also increases portability
2023-03-28 22:05:30 <vms14       > and the vm interpreter could be a transpiler too
2023-03-28 22:05:43 <crc         > I'm not really interested in transpilers or direct interpreters. My VM designs use a stack architecture, but aren't strictly for running Forth.
2023-03-28 22:07:17 <vms14       > I always thought that rather than making a vm I would just make a transpiler
2023-03-28 22:07:35 <vms14       > but I see several benefits the vm can give, including a transpiler xD
2023-03-28 22:07:55 <crc         > My main purpose is portability; I can easily port my vm designs to different hosts, and bring my tools and applications along.
2023-03-28 22:08:03 <vms14       > hmm
2023-03-28 22:08:31 <vms14       > initially looks like more work, but seems worth it
2023-03-28 22:08:41 <vms14       > also cleaner in some way
2023-03-28 22:09:33 <crc         > e.g., my smallest design, ilo, can be implemented in a new language in an hour or two, at which point I have a functional Forth, with some various tools
2023-03-28 22:10:14 <vms14       > crc what makes portability harder in a vm design?
2023-03-28 22:10:54 <crc         > vm makes portability easier, not harder (at least for minimalist designs like I use)
2023-03-28 22:10:57 <vms14       > I was thinking about a vm being able to be plugged with new code/instructions too
2023-03-28 22:11:25 <vms14       > yeah, I meant if you found something that could harm the portability a vm provides
2023-03-28 22:12:10 <crc         > My current designs make few requirements on the host, so are quick to implement, letting me bring my environment across host systems easily
2023-03-28 22:12:12 <vms14       > I'm wondering, but looks like it's worth giving it a try
2023-03-28 22:12:32 <crc         > the more hooks you provide into the host, the less portable it becomes, in my experience
2023-03-28 22:13:56 <vms14       > so the goal is to make a minimum set that would work on most platforms/langs
2023-03-28 22:14:23 <vms14       > then it could accept some kind of extensions or whatever
2023-03-28 22:15:07 <crc         > that's what I do :)
2023-03-28 22:15:25 <vms14       > crc how do you provide extensions? :0
2023-03-28 22:15:39 <vms14       > in a way similar to modules?
2023-03-28 22:16:20 <crc         > Depends. Often, I build a vm with extensions via whatever i/o model the vm provides.
2023-03-28 22:16:56 <vms14       > hmm
2023-03-28 22:17:06 <vms14       > I'll research stuff about vm
2023-03-28 22:17:10 <vms14       > ty crc :D
2023-03-28 22:17:47 <vms14       > it's also a good excuse to finally learn assembly, since I could make my own assembly lang and be able to use it for whatever I want
2023-03-28 22:18:43 <crc         > Sometimes I do odd things. In my newest system, I provide some extensions via an external process that reads and updates blocks. This is used to do things like provide time & date, access to /dev/urandom, and some host file i/o.
2023-03-28 22:19:15 <crc         > This way isn't very efficient, but doesn't require vm alterations
2023-03-28 22:23:46 <vms14       > you could make some sort of protocol
2023-03-28 22:24:11 <vms14       > in the sense of making something standard, so no matter what extensions you create, the vm does not need to be aware of
2023-03-28 22:25:13 <vms14       > in my case I'd put them on the vm directly via modules or something similar
2023-03-28 22:25:30 <vms14       > then check for extensions before use them
2023-03-28 22:25:44 <vms14       > but meh, isn't a thing I should be even thinking for now :D
2023-03-28 22:26:18 <vms14       > I should start with some simple fake cpu
2023-03-28 22:26:32 <crc         > Most of my designs are *very* minimal. I don't have loadable modules, so extensions are built into the vm binary or have to be provided by a separate process & accessed via whatever existing i/o the vm has.
2023-03-28 22:28:45 <crc         > My smallest system: http://fossils.retroforth.org:8000/ilo/file?name=doc/ilo.txt&ci=tip (spec document) and http://fossils.retroforth.org:8000/ilo/file?name=ilo.c&ci=tip (c code; there are other implementations at http://fossils.retroforth.org:8000/ilo/dir?ci=tip&name=vm )
2023-03-28 22:37:14 <vms14       > This is a implementation with two threads. One runs the CPU, decoding and processing instructions. The other watches for stack over/under flow situations and exits on errors.
2023-03-28 22:37:18 <vms14       > crc why? xd
2023-03-28 22:38:14 <crc         > experimenting with pthreads, in preparation for a larger vm that uses pthreads to run multiple simulated cores
2023-03-28 22:40:31 <vms14       > is weird to see a thread just for a stack underflow check
2023-03-28 22:40:32 <vms14       > XD
2023-03-28 22:44:07 <vms14       > what's so cool about forth block files?
2023-03-28 22:46:48 <vms14       > ah, they're just the alternative for when you do not have a system
2023-03-28 22:46:57 <crc         > this is somewhat hard to explain. I've grown to like them as an organizational aid; it makes sense to focus on a word (or small group of related words) on a block. This can encourage better factoring
2023-03-28 22:48:17 <crc         > At this point I've only been seriously using blocks for about a year, but have increasingly found myself using them on all my systems.
2023-03-28 23:33:33 <vms14       > The simulator tracks, for each register and memory value, the last time it was written to and the instruction that wrote to it. This can be invaluable for tracking down memory corruption errors (e.g., finding who is scribbling over memory) or otherwise determining why r1 holds an integer when you were sure it was supposed to hold a string.
2023-03-28 23:33:41 <vms14       > that's a cool debugging feature