Interpreted language (esp32 specific)

[adekto]

wel if you have the bytecode interpreter, you can write a optional compiler on device
and even do funky stuff like making it a visual scripting language since typing with a dpad seems like a pain

might even write that in the bytecode language depending on implementation

[FManga]

the reason for interpreter is mostly for the flash actualy, rpg project is rapidly running out of memory and have to ofload logic for specific combat events, quests, and “cutscenes”
on the other hand the esp32 project we cant reflash the esp32 (easly) so sending bytecode up to be executed seems like the best option, the idea here is to make it sort of general purpose and reusable for any other project that might need this

Ah, I see. I’m asking all these questions because, depending on the exact problem you’re trying to solve, different optimizations can be used.

Right now I’m stuck in a project with a tight deadline, but next week I intend to start working on something similar for the Bitsy engine port.

[adekto]

are you actualy porting bitsy or creating something similar?
i got sort of a idea for a visual scripting UI

[FManga]

wel if you have the bytecode interpreter, you can write a optional compiler on device
and even do funky stuff like making it a visual scripting language since typing with a dpad seems like a pain

might even write that in the bytecode language depending on implementation

If you’re going to put a compiler in flash, you can optimize for that. Specifically, you execute an AST instead of bytecode.

are you actualy porting bitsy or creating something similar?
i got sort of a idea for a visual scripting UI

I’m not sure if a port is the right name, but it’s not something similar. It translates existing Bitsy games into C++. Bitsy games have scripts for logic, and since I haven’t looked into the language yet, I’m not sure if I’ll be able to translate that into C++, so I might have to port their scripting engine.

[adekto]

what will that accomplish? wasn’t the point of easily swapping out the small bitsy games? maybe i miss understood that project

[FManga]

It’s the quickest way to get bitsy games running on the Pokitto. Once this part of the work is complete, making it parse bitsy games from the SD card is not that hard and can be done later if we really need to.
Alternatively, we could just translate them all en masse and run them like normal Pokitto games.

Edit: Basically, the Bitsy games can be seen as a whole lot of data. Too much data to fit in RAM. Loading that data is half of the problem. If I put this data in flash, I can (temporarily?) skip this entirely. Running the game is the other half of the problem, and it’s the one I’m tackling first. Kind of backwards, but it lets us test things from the start.

[Pharap]

I was refering to a scenario where bytecode is on the SD card, without a compiler in flash.

For the case of the ESP chip, the ability to upload new scripts while it’s still running without flashing the chip.

For the case of the RPG, to load the script from SD into RAM, again without flashing.
The maps will probably have several scripts that need to be loaded along with the map.

Though in the ESP case an on-board compiler might make sense, depending on what sorts of scripts are needed.

might even write that in the bytecode language depending on implementation

Bootstrapping the compiler would almost certainly make it larger and slower than implementing it C++ side.

[adekto]

to come back to a simple interpreted language, just to experiment with
what could we try?

[Pharap]

The Pawn language itself looks quite simple:
https://wiki.alliedmods.net/Pawn_Tutorial

But the source code is less simple.

I think Forth might be out of the question, the only open source implementation I found was written in F#.
Could write a custom one I guess.

I think whichever option you pick it’s going to be difficult.

[FManga]

to come back to a simple interpreted language, just to experiment with
what could we try?

Lisp. I think a parser, AST and minimal VM could be made to run useful code with not that much effort, if an existing implementation can’t be used.

[adekto]

omg thats an amazing one, i see esp8266 is suported wich upgrading to esp32 should in theory be trivial

i dont know anything about lisp though apart from it might have been used for crash bandicoot on the ps1

[Pharap]

Lisp.

Three questions:

• Which variant is that most similar to?
• Is the compiler a resonable size?
• Have you ever written/used a LISP?

i dont know anything about lisp though

It looks like this:

(defun area-circle(rad)
   "Calculates area of a circle with given radius"
   (terpri)
   (format t "Radius: ~5f" rad)
   (format t "~%Area: ~10f" (* 3.141592 rad rad))
)
(area-circle 10)

[adekto]

from there homepage

The language is generally a subset of Common Lisp, and uLisp programs should also run under Common Lisp.

it can run on an Arduino uno which puts the bar low enough for specs

RAM: At least 2 Kbytes.
Program memory: At least 32 Kbytes (the program currently uses about 29 Kbytes of program memory on the Arduino and 31 Kbytes on the MSP430).
EEPROM, flash, or FRAM memory: Used for saving and loading the uLisp workspace.

It looks like this:

oh is it using polish notation? it looks fairly clean and straightforward

[FManga]

Three questions:

Which variant?
Is the compiler a resonable size?
Have you ever written/used a LISP?

It’s not like we need to maintain backward-compatibility with anything, we’re not trying to run Emacs on the Pokitto. If a port can be used, then that variant, whatever it is. If a new implementation would need to be done, then implement just what’s necessary, make a new variant.

The syntax is simple, it uses RPN and it’s practically an AST, so the compiler shouldn’t be too big. I can’t think of an easier language to get running (except, maybe, one of the esoteric/useless ones). Especially if only a subset is used.

I’ve written mostly small snippets as that’s what Emacs uses for everything.

[jonne]

The Pawn language itself looks quite simple

I’ve used Pawn. Getting it running is relatively simple and in program size it beats everything else hands down.

Edit: compared to Lua and other full feature programming languages. Don’t know about uLisp etc

And I got partcl running on pokitto easily
https://zserge.com/blog/tcl-interpreter.html and that is tiny

[Hanski]

Just go on an create your own. That will certainly be a very educating and fun experience. Just decide what your target is to keep the work amount manageable: showing graphics, creating UIs, making game logic, etc. You could even target it for coding tiny scripts on Pokitto itself on-the-go

To make it easy for others to take it into use in different environment, try to put everything to just few C++ source files, make a very simple interface and keep dependencies to other libraries to the minimum.

[adekto]

Not sure how to get lisp running on the esp32
It’s complaining about some Arduino stuff, idk

Did get a version of forth on it called “fvm Arduino”

Whats a good way to benchmark this?

[adekto]

Oh I totally forgot, I pulled pin 12 on esp32 high and it then has a build in version of basic
It’s not much it seems to work
How can I hook this up to the pokitto? Currently it’s running in a serial monitor at 115200 baud

[Pharap]

oh is it using polish notation?

Technically it’s reverse polish notation.
Polish notation would be (10 area-circle) rather than (area-circle 10).

Nope, you’re right.
Polish notation is prefix notation and reverse polish notation is postfix notation.
I got a bit confused there for a minute.

It’s not like we need to maintain backward-compatibility with anything

I never said anything about backwards compatibility.

I’m asking about variants because the variant defines what can and can’t be done.

The syntax is simple

The syntax is simple, but the language itself isn’t particularly easy to use.
If you’re used to functional languages (e.g. Haskell) then it’s not too strange, but if you’ve only ever done procedural languages (which is probably the case for most people here) then it’s going to be significantly alien.

Not just because of the RPN syntax, but becuase of the lack of arrays and use of cons-lists. Cons-lists take time to get used to.
(Forth on the other hand does usually support arrays and dynamic allocation.)

I’ve used Pawn. Getting it running is relatively simple and in program size it beats everything else hands down.

In that case I’m definitely leaning towards Pawn then (for the ESP hat).
Aside from its small size, its C-like syntax will be more familiar to people here so there’s less of a learning curve.

And I got partcl running on pokitto easily
https://zserge.com/blog/tcl-interpreter.html and that is tiny

A very interesting link.
Worth looking at even if only to hear the author’s opinions of the other languages (a number of which we’ve actually mentioned/considered already).

My concern about TCL would be the speed, even if the ESP chip is reasonably fast.

Just go on an create your own. That will certainly be a very educating and fun experience.

I agree with this for the RPG case,
but for the ESP case I think it would be too much effort and end up not being general purpose enough.

[adekto]

Still looking for the right language I talked to a local teacher.
There doing something new with kids in school these days,
Programing but it’s all node/block based
So maybe at least on the end user this might be a good idea

There using a couple of them and use them on Arduino and micro:bit type devices

There still have to use PC or iPads to do it though Wich is expensive for some schools, maybe on device programing could help with that?