5 ms·

Hello! Author of this project here. Thank you for posting this to HN. A little background about this project: This is a tiny project inspired by the very popul

by susam 3y ago

Hello! Author of this project here. Thank you for posting this to HN. A little background about this project: This is a tiny project inspired by the very popular Tixy project (https://tixy.land/ https://tixy.land/). While Tixy supports JavaScript expressions to determine the size and colour of circles in a 16x16 grid, FXYT comes with its own tiny, stack-based language that is written in postfix notation. The input code is evaluated for each cell in a 256x256 grid and the result of evaluation defines the colour of each cell. Some demos: 1. https://susam.net/fxyt.html#XYxTN1srN255pTN1sqD https://susam.net/fxyt.html#XYxTN1srN255pTN1sqD 2. https://susam.net/fxyt.html#XYaTN1srN255pTN1sqN0 https://susam.net/fxyt.html#XYaTN1srN255pTN1sqN0 3. https://susam.net/fxyt.html#XYoTN1srN255pTN1sqDN0S https://susam.net/fxyt.html#XYoTN1srN255pTN1sqDN0S 4. https://susam.net/fxyt.html#XYpTN1srN255pTN1sqD https://susam.net/fxyt.html#XYpTN1srN255pTN1sqD 5. https://susam.net/fxyt.html#XYN256sTdrD https://susam.net/fxyt.html#XYN256sTdrD Visit https://github.com/susam/fxyt https://github.com/susam/fxyt for more details.

o11c 3y ago
Ouch those limitations though. Given the performance problems some of them sort of make sense I guess, but: * adding "get by index" and "put by index" commands would significantly improve flexibility compared to only being able to access 3 elements of the stack (admittedly less useful given the limit of 8 total) * if you perform a sort of pre-compilation pass to generate a sort of bytecode (even to just an array of functions, though I would also add an argument field since stack form sucks), and optimize constants like numbers, execution will be much faster.
- chmod775 3y ago
  > if you perform a sort of pre-compilation pass to generate a sort of bytecode Generate JS and throw it through eval/new Function. The JS engine is going to beat by a mile whatever you can come up with within the constraints of JS.
  - Lerc 3y ago
    That's more or less what I did with C50. I wrote a simple translator to turn the stack based code into JavaScript expressions, then created a function via new Function. It came out a couple of orders of magnitude faster than the interpreted version.

by susam 3y ago

o11c 3y ago

Ouch those limitations though. Given the performance problems some of them sort of make sense I guess, but: * adding "get by index" and "put by index" commands would significantly improve flexibility compared to only being able to access 3 elements of the stack (admittedly less useful given the limit of 8 total) * if you perform a sort of pre-compilation pass to generate a sort of bytecode (even to just an array of functions, though I would also add an argument field since stack form sucks), and optimize constants like numbers, execution will be much faster.

chmod775 3y ago
> if you perform a sort of pre-compilation pass to generate a sort of bytecode Generate JS and throw it through eval/new Function. The JS engine is going to beat by a mile whatever you can come up with within the constraints of JS.
- Lerc 3y ago
  That's more or less what I did with C50. I wrote a simple translator to turn the stack based code into JavaScript expressions, then created a function via new Function. It came out a couple of orders of magnitude faster than the interpreted version.