> I still prefer infix notation to prefix notation for an intermediate > language. I don't understand why it is so hard to adopt. imcc is supposed > to be a step closer to higher level languages, which is why I went that > way.
Hi, I think we all agree that since parrot can have dynamic oplibs (and core parrot has hundreds of ops), imcc needs some way to directly express them. The idea of having parrot ops be included as such, and imcc directives be prepended with "." looks fair to me. So we end having: a) imcc becomes like parrot assembly, but with virtual registers and a few administrative ops (for calls and such), that start with "." or b) imcc becomes like parrot assembly, but with virtual registers, a few administrative ops, and some convenient infix notation like for stuff like "a =1" or "b = a + 1", There isn't much difference between both proposals, when you think about it. The only benefit of proposal b) is that hand-writing of imc becomes nicer, but i would not expect much of it. Additional to the learning benefit for developers of parrot-based languages, the usage of parrot ops "as is" is good for us, because we don't need to invent, develop, and document, another language. It lets us focus on making imcc do well a few tasks (ahem) such as register allocation and language-neutral optimitzations. >From a more conceptual point of view, I would favour imcc being as similiar to the assembler as possible because: - parrot assembler is already very high-level - imcc won't probably be retargeted to a different plataform. If we really wanted to make imcc retargetable, we would need much more than a friendlier syntax; and honestly I am not sure that is worth it. To sum up, my vote would be for a assembler-like imcc. The infix notation doesn't add much value in a intermediate language such as imcc. I am not a priori against imcc diverging from assembly. But I think the only good reason for divergence should be making the task of the language compiler simpler. About the implementation, I think we will need the following metadata about each op: i) the opcode, and the op name. ii) the type of arguments, including in/out/etc.. iii) whether the opcode has side-effects or not. This is important for a number of optimizations: constant-folding, optimitzations that work by moving a instruction to a more convenient point, etc. Best, -angel
