Hi, Andy Wingo <wi...@pobox.com> writes:
> What I'm getting at is that I think we should have VM ops for working on > vectors -- both generic vectors, and specific ops for bytevectors, and > probably an op for string-ref as well, and possibly string-set!. Then a > native code backend could be effectively implemented to operate on the > GLIL or assembly level, relying on the Tree-IL compiler's previous > resolution of high-level operations (i.e., vector-set!) to low-level > instructions. I think we have the space in the VM, and if we group all > of the vector instructions at the end, we shouldn't affect the > instruction cache too much. Why not, but... It looks to me like a failure to optimize the general case, which we work around by specializing the instruction set. Maybe we could have a more generic approach to the problem. For instance, there could be a way to annotate primitive procedures with information useful to the compiler, such as "returns-single-value", "return-value-unspecified", etc., which would allow the generated code to take shortcuts. But maybe this is just unrealistic. What do you think? Thanks, Ludo'.
