howerj / embed Goto Github PK

putting this on github since someone on ##forth IRC was asking about it

#include <err.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <embed.h>

int unix_putch(int ch, void *file);

int
main(void)
{
	setvbuf(stdout, (char *) 0, _IONBF, (size_t) 0);

	cell_t m[EMBED_CORE_SIZE] = {0};
	embed_t h                 = {.m = m};

	embed_default(&h);

	embed_opt_t o = embed_opt_default();

	o.in      = stdin;
	o.out     = stdout;
	o.put     = unix_putch;
	h.o       = o;

	// engine "primed" -- this removes the bad condition?
	//embed_eval(&h, "\n");

	embed_push(&h, 17);
	embed_push(&h, 71);
	printf("depth %lu == 2\n", embed_depth(&h));

	// the + does not happen?? (nor the .s) unless the engine is
	// first "primed"?
	embed_eval(&h, " .s + .s \n");

	cell_t value;
	size_t d = embed_depth(&h);
	printf("depth %lu == 1%s\n", d, d == 1 ? "" : " ??");
	while (d) {
		embed_pop(&h, &value);
		printf(" %d", value);
		d--;
	}
	putchar('\n');
	return 0;
}

int
unix_putch(int ch, void *file)
{
	int r = fputc(ch, file);
	return r;
}

So this software is very interesting.
It looks like you are free of the GPL.
AFAIK, All of the other versions of the J1 depend on GForth and its gpl license.
You may want to highlight that this is gpl free software for the J1.

It is a good reason for it to spread.

@howerj Thanks for your great work! It is amazing!

I can see the image of VM is stored in the C array embed_default_block of image.c as below:

when I checked the makefile, I can see this C array is derived from embed.fth by
embed.exe -o embed-1.blk embed.fth.

However, the embed.exe above has been loaded into the image. It goes into chick&egg problem. I am wondering how we get the first VM image which can interpret embed.fth?

I am stuck there, can help answer?

Hi Richard,

Carlos has been having trouble getting the "Call" demo to work. The concept for how to integrate FORTH commands with the surrounding C environment makes perfect sense but we're just not getting the the expected results. Can you provide guidance on how we can get things working properly on our end?

Dave

Hi,
We are trying to debug an infinite loop scenario, executing the following commands:

1. First we define the following word:

: looping begin 1 - dup dup . 0 = until ;

2. And then we run an infinite loop like this:

-1 looping

The VM runs fine, we show the expected outputs, even we have integrated the yield and putc callbacks!! (we yield and resume the VM later)
but after a while it stops at this position for the internal pointers:

VM finished: pc [274] t [18432] rp [32759] sp [9216]

At this point, the VM considers that the command was completed and finishes its execution.

Are we doing something wrong with the loop definition? What is the root cause of this stop?

Thanks and regards

Hi Richard. I just have a quick question for you. How does a user remove words from a dictionary after they have been added? I think some versions of FORTH have a flush command that resets the dictionary pointer. Do you have any suggestions on how to implement this in embed?

Hi Richard. Do you happen to have a memory map for the VM to show where the the dictionary, stacks, and other internal components are located? Also, what is the anatomy of a FORTH definition? For example, do definitions use a three character name field followed by link, code pointer, and parameter fields? I'm working on developing a tutorial for Ex Machinis players and want to start digging into memory use and configuration.

Dave

Hi Richard, hope everything is fine at your side.
Do you remember us? We were working with your embed project a long time ago, lol.
So far, so good. But now we need to go a step forward and define inside the FORTH virtual machine new words for our own purposes (default words).

We have tried these steps:

1- Modify the embed.fth file, adding this line:

: 2drop drop drop ;         ( n n -- )
: 1+ 1 + ;                  ( n -- n : increment a value  )
: 2+ 2 + ;                  ( n -- n : increment a value by two )     <---- This is new, added by us

Then running:

./embed -o newvm.blk embed.fth 
FORTH META COMPILATION START 
COMPILATION COMPLETE
HOST:    3F48
TARGET:  1528
HEADER: 
  5000:     14     0  7FFF  2400   347  8000     0    14  _______$G_______
  5010:      0  7FFF  2400  4689  4854   A0D   A1A  1528  _____$_FTH____(_
  5020:   4DEA     1  1984     1   949  628D  601C  628D  _M______I__b_`_b
  5030:   631C  10E0  151E     0  7003  6461  4017  4100  _c_______pad_@_A
SAVING...DONE
STACK> <sp

We generate a new VM with this new word.

The problem we find is that this new VM image seems to not contain our word 2+.

Are we doing it correctly? Could you share some quick guidance on the steps required otherwise?
Thanks in advance and best regards.
Carlos & Dave

Dear @howerj,

I am looking for a way to add scripting to a project on a small embedded platform with very limited RAM (ESP8266) and Embed seems to be a very promising option! However, the default image requires much more RAM than available on this system. I am not sure, how to change this, perhaps you give me some hints?

• What changes are required to change the VM memory size to a lower value (e. g. $1000 cells)?
• Would it be possible to move some precompiled code (e. g. embed.fth) to flash memory? Flash memory read access must 32 bit aligned to avoid segmentation faults.

Thank you very much for your help!
Matthias

As you know, we've been using embed to support a multiplayer space game in which player's use FORTH to program their drones. We're at the point were we would like give the interpreter control of in game processes like flying the spacecraft. What would be the best way to call external routines from within the FORTH environment?

For example, we would like to have a FORTH command that tells the spacecraft to orbit a specific planet. "4 Orbit" would tell the spacecraft to orbit the fourth planet from the sun. "Orbit" would need to call an external C routine, which pulls 4 off the stack and relocates the ship to an orbit around Mars. Is there a straight forward way of doing this?

Dave

I'm thinking about porting this to a Raspberry Pi Pico. I'm not opposed to a 16-bit Forth, but the Pico is a 32-bit machine (264Kbytes RAM, 2 Mbytes flash, Arm Cortex M0+). How difficult would it be to do this port?

embed.c.txt
vm.c.txt

Hi Richard, we have started to integrate EMBED in our project and have some issues when we save VM into memory and then try to reuse it again (loading again from memory).

I share with you here our codes so far (vm.c is our interface that calls the embed.c routines), this module wraps the forth_t inside another type called VirtualMachine_t, just to make things easier but it is just a wrapper.

I have created a new function at embed called embed_eval() just to mimic what embed_forth() does but this time using an input string and recovering VM output in out buffer (instead of using stdin/stdout).

Apart I have created just a couple of functions to create a VM from memory or to memcpy it into memory (this chunk of bytes is what we store at DB).

Also I have integrated embed.c with our engine_trace() function to display log info.

The things go fine when we create the VM for the first time, we can run the first command and retrieve the output. We receive even the first lines of the VM prompt/console.

Then we store the full VM struct (forth_t) into memory (once this first command is executed).

After a while we retrieve this chunk of memory and try to run a different command, using embed_eval() again with the VM loaded from memory.

At this point we got stalled, the VM keeps answering always the same result (the answer to the first command we issued), regardless input command, seems that it keeps in the same state or does not save something before finishing.

Hope you can give us a hint of why it is happening this, thanks a lot
Carlos