4 ms·
> After extensive optimizations it turns out, that the interpreted code is not significantly smaller than the native code in most scenarios (although there are
by zellyn 3y ago
> After extensive optimizations it turns out, that the interpreted code is not significantly smaller than the native code in most scenarios (although there are cases where the difference is significant).
Does that mean that the whole thing was ultimately a failed experiment, or that the native code optimizations have become so good that the interpreted mode is made obsolete in most situations?
- drmortalwombat 3y agoIt turned out that for most cases, there is no gain by using an interpreter. Most code that does make any sense on a C64/6502 is compiled into a smaller and faster native version. For some code e.g. heavy floating point or many pointer indirection the interpreter wins on the memory size - but this is not a good use of a C64.
- soegaard 3y agoThe idea of using an interpreter to save space is sound. Wozniack used that idea in SWEET16 for the Apple II (also 6502 based). https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16 https://www.youtube.com/watch?v=vGdEN9Z7owg https://www.youtube.com/watch?v=vGdEN9Z7owg
- drmortalwombat 3y agoThis was my assumption as well, when I started this compiler. It just did not play out this way with most code that I have written for it. The native code optimizer is able to reduce 16bit arithmetic to 8bit in many cases, where it can prove that the value range is small, and also avoid many pointer/stack operations by global call chain analysis. Both benefit the native code path