Login
Community
DARK THEME

Working on a new language engine for microScript v2

I have been working on microScript v2 this week. I wanted to validate the general principle of a new microScript engine, which works as an interpreter, based on a stack machine and an intermediate language representation. I started doing some benchmarks to check whether I was getting good performance. From the start, the performance was quite good (much better than microScript v1 interpreter) but still significantly behind transpiled microScript v1. I worked on it, made many smaller optimizations... until I realized one possible optimization was to mix interpreted instructions with transpiled chunks of code, without losing the benefits of the new engine architecture (I will detail some of the benefits below).

The final result is that the engine is working beautifully. microScript v2 will not be exactly as fast as transpiled v1, but it will be very close (actually, on FireFox it is slightly faster! But not on Chrome). The language itself should include all of microScript v1 (thus your existing projects are ready for it!), with a few new language features (binary operators, multi-line comments, type checking...)

The benefits of the new architecture will be:

  • no more "timeout" restrictions ; you can write and run code computing for minutes or forever without problem
  • opens the possibility to pause execution for a certain amount of time, like a sleep function, e.g. waiting 1 second before doing something. This has been requested a lot.
  • opens the possibility to easily schedule tasks ahead of time (like setTimeout / setInterval in JavaScript). This has been requested a lot too.
  • opens the possibility to run threads or coroutines for parallel tasks
  • opens the possibility to set breakpoints (for a future step by step debugger)
  • opens the possibility to record profiling data (find where most of the CPU time is spent in your code)
  • makes it easy to publish your game with obfuscated code (some people asked for this too)
  • is a solid foundation for a future native microScript engine written in C or C++

Regarding paused execution, scheduling tasks and threads, I am trying to find a nice syntax. I am considering the following:

sleep(1000) // pauses execution for 1 second

in 5000 do  // schedules execution of all the enclosed code when the delay of 5 seconds is elapsed
  callSomeFunction()
  count += 1
end

thread = do // shortcut to start a thread without delay, identical to "in 0 do ... end" 
  makeSomeHeavyComputationInParallel()
end

thread.pause() // pause the thread
thread.resume() // resume the thread
thread.stop() // terminate the thread ; the thread cannot be executed anymore

Let me know what you think of all this!

in 5000 do  // schedules execution of all the enclosed code when the delay of 5 seconds is elapsed
  callSomeFunction()
  count += 1
end

Just so I understand, would the above piece of code be put in the main Update() .. end loop? What, for example if you want do a one-shot call only? Perhaps another keyword?

after 1000 do StartGame() end // after one second call the function once only

I remember from the days of the Amstrad 464 the basic language used every to set up a timer that runs every x ticks:

every 1000 do UpdateAlien() end // every second call this function

In any case the in keyword is easy to remember.

To clarify, the code above will trigger a single execution of the enclosed instructions, after 5 seconds is elapsed. You probably don't want to put that directly in update() because you would schedule 60 such delayed tasks per second (which would work but certainly not what you want!).

I think your syntax with after is more clear, maybe I should switch to that instead of in?

every was also suggested by @Thad on Discord and I think I will go for it!

Also I have considered allowing to specify the time unit, like this:

after 2 seconds do ... end

// or

every 100 milliseconds do ... end

So you don't have to ask yourself whether this language wants seconds or milliseconds as time parameter. Also it is more pleasant to read, isn't it?

What do you think?

Will after and every return a thread object too? So we can cancel ot stop at needs?

The subject is really interesting and opens a lot of possibilities to easily struct the code for cut scenes, animations and other goodies.

Yes after and every will return a thread object too!

Post a reply

Progress

Status

Preview
Cancel
Post
Validate your e-mail address to participate in the community