automatic unboxing/boxing + stack context

[pmp-p]

I know the goal is to fully AOT, but thinking of embedded and micropython/wapy and especially wasm in its current form it could be an interesting option to have hooks around(in?) C++ functions ( c++ and parser newbie here so just silly asking) to do something like:

/*
ctx is the macro pointing one elem in a register array ( push/pop )
1 array per cpu , one thread per cpu. size of vm sys recursion
*/

#define ctx REG[CURRENT]

the compute block can be left and re entered any time.

ctx_type  run_fonction( ) {
   // in Pascal self would be the  struct made from the Var block preceding Begin/End;
  // and it's way better than bad C, just for that local scoping constraint.

  if !ctx.state : self = allocstack(ctx); ctx.self = self
  else:
      self = ctx.self 
      goto comefrom_[ctx.state]
  ctx. state == 1 ; 

  #maybe define a macro block for locals redirecting names to heap  to keep some readability
  # in wapy transpilation all (pseudo) locals() are adressed via  self->name from self.name

  while (;;) { 
      // heavy computation loop 
      // no locals() in that scope, maybe check for reentrance if using statics.
         while (;;) {
         {
             // locals allowed for temporary
             // very light computation
            
         }

        if exception { ctx.state = -1  //optionnal ; ctx.line = __LINE__ ;  ctx.ex =  ?; // yield }
 
       // time to pre empt or some I/O is needed
        if rt alarm check {
           ctx.aio  =1 ;
           goto yield
        }


        // yield a value
        ctx.return_value
        ctx.gen = 1
        goto yield
comfrom_1:
     }
#undefine macro block

   ctx.state = -1 

   ctx.return_value = (c++_type) result ;
yield:
  return ctx
}

an almost normal AOT call from mys suitable for running in an OS

c++_type  msys_fonction(ctx,*argv) {
   // same as upper but with no (un)boxing
CURRENT++
   ctx.argv = &argv 

  while (;;) {
      run_fonction(ctx);
 // ***************************************************************************
 // absolutely no idea how to implement the comefrom here and
//  mys alone probably does not need it and can use OS sleep preemption.

      if ctx.stat<0 break
  }
  c++_type rv =  ctx.return_value;
  unallocstack(ctx);
CURRENT--
  return rv;
}

A call from top of a VM.

_start/main scope {
// VERY simplified, probably wrong
// far from a real function here, in wapy functions are juste jump labels
// stack pointer targets heap and is stored in ctx registers,  whole code segment is  surrounded by a control flow handler
//  that jump / unwind from ctx state machine.

// rv is always opaque pointer  box_t  

argv is provided by the vm stack.
so a function call is :
{
  CURRENT++
   ctx.state = 0
   ctx.aio = 0
  ctx.argv = & unbox( *argv ) 
  goto some_dynamic_vm_fonction;
  return_HERE:
  push return_value
  unallocstack(ctx);
  CURRENT--
}

some_dynamic_vm_fonction:
     ctx.result_type = c++_type;

     again :
      run_fonction( ctx , *unboxedargv)
      if ctx.aio > 0 :
           goto syscall with return to again 
           
      if ctx.state <=0  :
           do whatever required to break from generator  handler usually store an exception.
      
      // generator, exception(null) or final value
      return_value =  new_box_t( ctx.return_value )
      goto return_HERE;
}

I don't know how easy it's to write coroutines or do bare metal RT with C++, but i would highly appreciate the ability to write RT modules for wapy-micropython-pycopy with mys, as it's not that hard to do it in C99 + not using c-stack i have some hope for C++, what do you think ?

[eerimoq]

So basically you want something similar to Python's async, right? A single threaded application with a cooperative scheduler of light weight tasks. It could be doable, but I'm not sure. Right now async is out of scope as it's lots of work and no obvious big advantage in the general case.

The reason for generating C++ is that C++ has more similarities to Python than C does. Classes, exceptions, etc. If Mys is successful the transpiler could be redesigned to generate C code instead, given that there are good reasons for it.

[pmp-p]

after WASM cross compilation and playing a bit with SDL2+window.requestAnimationFrame() and raytracing, i'd say that cooperative scheduler is not the way, it should be pre-emptible coroutines. with a coroutine storage context in the heap and deadline scheduling.