You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Long term, we're going to want to get scas running on a KnightOS system natively. Unfortunately, as is, scas isn't nearly efficient enough for this, even assuming KCC was capable of compiling it to a small enough size.
The first, most easily approachable problem: memory usage. Cleaning the memory leaks was a good first step, but the memory usage is fundamentally inefficient - broken by design, in other words - in multiple ways. Firstly, the list_t type needs a total revamp. As is, it requires all items to be pointers, which forces a lot of heap allocations, including full, unneeded string duplications. Fixing this should reduce peak memory usage and improve performance.
Performance right now is quite excellent, on modern hardware. This isn't good enough. Ideally, it needs to be fast enough to assemble the entire kernel in 50ms on modern hardware, tops. Since most projects are much smaller than the kernel, that should allow smaller projects to compile in less than 10ms on a reasonably recent AMD64 chip - which gives three orders of magnitude as a buffer for the z80 to be acceptably fast.
The actual self-hosting of scas will require much more work to get code size itself down, and will probably require doing a one-time compilation into z80 and manual cleanup and optimization of the generated code. We'll also probably need to tweak the design further beforehand.
Redesign list_t to avoid requiring heap allocations for items
Avoid string duplications
Figure out what else is needed
The text was updated successfully, but these errors were encountered:
Long term, we're going to want to get scas running on a KnightOS system natively. Unfortunately, as is, scas isn't nearly efficient enough for this, even assuming KCC was capable of compiling it to a small enough size.
The first, most easily approachable problem: memory usage. Cleaning the memory leaks was a good first step, but the memory usage is fundamentally inefficient - broken by design, in other words - in multiple ways. Firstly, the list_t type needs a total revamp. As is, it requires all items to be pointers, which forces a lot of heap allocations, including full, unneeded string duplications. Fixing this should reduce peak memory usage and improve performance.
Performance right now is quite excellent, on modern hardware. This isn't good enough. Ideally, it needs to be fast enough to assemble the entire kernel in 50ms on modern hardware, tops. Since most projects are much smaller than the kernel, that should allow smaller projects to compile in less than 10ms on a reasonably recent AMD64 chip - which gives three orders of magnitude as a buffer for the z80 to be acceptably fast.
The actual self-hosting of scas will require much more work to get code size itself down, and will probably require doing a one-time compilation into z80 and manual cleanup and optimization of the generated code. We'll also probably need to tweak the design further beforehand.
The text was updated successfully, but these errors were encountered: