Mugo, a toy compiler for a subset of Go that can compile itself

For many CLIs I think even a brain-dead bump allocator would work

https://github.com/fosslinux/live-bootstrap/blob/master/part...

The steps go from a binary seed of a few hundred bytes to (almost) gcc. It is still being actively developed as part of the Bootstrappable Builds project:

https://www.bootstrappable.org/

You could compare it with PyPy, a just-in-time compiler for python.

For example, on my machine, the same program runs in 2:12 min with the regular python interpreter, and in 1.57 seconds with pypy.

To get the correct answer, we need to convert some of the numbers to BigInts

  var result = 0n

  function main() {
    var sum = 0n
    var i = 1
    while (i <= 1000000000) {
        sum = sum + BigInt(i)
        i = i + 1
    }
    result = sum
  }

  main()

  Now using node v15.6.0 (npm v7.4.0)
   time node index.js
  node index.js  51.50s user 0.40s system 103% cpu 50.072 total

^1 Most likely because it generates C code and has to call an external C compiler to get things done.

As for why Node runs quickly, adding integers (or floats or whatever) is easy mode for a JIT. This is basically why you see JIT numbers like speeding up the original implementation by factors of literally over 100x, yet you can't expect that multiplier against "real code", for essentially the same reason only now on the other end; the JIT can very successfully cut out all that work CPython or similar implementatiors are doing if you have completely stable types that it can infer (especially something as simple as a single int or float), but now the "payload" is preventing the JIT from posting big numbers in improvement when you have more complicated operations because the JIT isn't going to be able to improve something like a substring search. If you get something like NumPy where you can feasibly write a program that will spend 99+% of its time in highly optimized matrix code, a JIT can't help much with that, because even if it reduced the bookkeeping to zero, you've still got to do all that matrix work.

Statically-typed compiled languages basically bypass the whole "do lots of expensive bookkeeping to permit very flexble coding styles, then write a JIT that figures out how to bypass that expensive bookkeeping as often as possible" to simply constrain you to write in the fast subset in the first place.

    $ time python -c 'sum = 0
    > for i in range(1000000000): sum += 1'

    real 0m56.655s
    user 0m56.646s
    sys  0m0.008s

    time python -c 'sum(range(1000000000))'

    real 0m8.693s
    user 0m8.684s
    sys  0m0.008s

    $ time python -c 'import numpy as np; np.sum(np.arange(1000000000))'

    real 0m2.022s
    user 0m1.661s
    sys  0m2.061s

Its not a limitation of the parser, but simply that having variable declarations anywhere makes the compiler more complex. Its harder to calculate stack space / stack pointers when the variables are declared all over the place.

   ORB - symbol table handling - 430 lines
   ORG - code generator (for RISC) - 1115 lines
   ORP - parser (calls scanner and code generator - 997 lines
   ORS - scanner/lexer - 312 lines