retroforth/nga-c
crc fc2d232a2f bring in wip nga-c vm from main retro repo; the vm used here will be based on this
FossilOrigin-Name: 7b74314fd35d93c6c28cbbd38599e602a21fdc12a2b87e2e7340054dba83fc13
2021-04-14 19:22:54 +00:00
..
assemble.retro some experimental vm and tooling stuff (nga-c) 2021-04-08 19:51:34 +00:00
devices.retro some experimental vm and tooling stuff (nga-c) 2021-04-08 19:51:34 +00:00
extend.retro some experimental vm and tooling stuff (nga-c) 2021-04-08 19:51:34 +00:00
GNUmakefile some experimental vm and tooling stuff (nga-c) 2021-04-08 19:51:34 +00:00
image.c nga-c: fix hang when building 2021-04-14 11:55:46 +00:00
listen.retro nga-c: fix hang when building 2021-04-14 11:55:46 +00:00
Makefile nga-c: new vm: add support for embedded image 2021-04-14 11:53:01 +00:00
nga.c nga-c new: more refactoring, remove -s paramater; Also updates to main makefiles 2021-04-14 13:06:46 +00:00
ngaImage nga-c: fix hang when building 2021-04-14 11:55:46 +00:00
README.md bring in wip nga-c vm from main retro repo; the vm used here will be based on this 2021-04-14 19:22:54 +00:00

I'm exploring some things around the VM implementation and tooling; this directory contains the relevant files for this. Things I'm working on in this: [x] Single file implementation [x] Modular I/O (enable/disable at compile time) [x] Faster opcode processing [x] Removal of image saving from the C sources [x] Building extended image w/o retro-extend in C [x] Assemble new image w/o retro-muri in C [ ] Support for embedding device words in the C source [ ] Embed image in the C source using tool written in Retro

Specifics:

Retro's build process is a little messy. We first compile the assembler, then retro-extend (which is an Nga-in-C, with a reduced set of I/O). These are used to assemble the kernel, merge in the stdlib and any device words, then the VM is compiled, user-level additions are added to a new image, and then the source is updated before being rebuilt.

In this, the VM is built, then is used to assemble and build a new image, eliminating the need for separate retro-extend and retro-muri binaries.

In the longer term, there is benefit to having a standalone set of supporting tools, so I'm not going to eliminate them, but using Retro itself for more is something worth doing IMO.