Here is an attempt to solve the 2023 edition of the Advent of Code on my VM8 system:
the VM8 is an 8-bit micro-computer with 64 Kbytes of ram, running its own development tools (ie. a simple disk operating system for the SDcard module, an editor and an Oberon compiler).
The system's performance is lower than the one of dedicated systems: because the processor (ATmega162) has an Harvard architecture, it cannot run native code from ram so actually it spends all its time interpreting the bytecodes produced by my Oberon compiler. But then this means that the system is able to dynamically load any program and interpret it from the ram.
To give an idea of the computation performance, the calculation of fibonacci(42) using the following function takes 4 hours 44 minutes 52 seconds.
PROCEDURE fibonacci(n: INTEGER):LONGINT;
VAR result: LONGINT;
BEGIN
IF n < 2
THEN result := LONG(n)
ELSE result := fibonacci(n-1) + fibonacci(n-2)
END;
RETURN result
END fibonacci;This means that the Advent of Code puzzles have to be solved with algorithms that avoid brute force approaches...
I've noticed that more and more puzzles of the Advent of Code requires 64-bits integers... It's a bit of problem with my Oberon implementation where INTEGERs are 16 bits, and LONGINTs are 32 bits, so I have to use a library of multi-precision numbers...
These Advent of Code puzzles are a nice occasion for me to test the power of my VM system, sometimes they might reveal a bug...
DAY 6: After doing the first part with brute force, I noticed the problem can be solved mathematically, so a program is not necessary. However, to compute the solution with my system (it only supports single-precision floats), I had a lack of numerical precision... so I actually used a calculator...
DAY 8: Argh, part 2 revealed a bug in my multi-precision division algorithm, sometimes the results are wrong. So I had to workaround the bug by dividing the small numbers instead of the big ones... TODO: fix that division bug.
DAY 12: I surely haven't found the good way to address the problem, part 1 already takes 37 minutes on my system... Surely this comes from the fact I am calculating the same things again and again due to the recursive scheme... Of course this does not scale up for Part 2, so I am leaving it for now, I'll try to think about it later...
DAY 14: despite optimization of the Tilt operations, Part2 is still a bit slow (several minutes), and the approximative initial number of cycles was obtained by my Linux version...