develooper Front page | perl.perl6.internals | Postings from August 2002

Re: imcc hack for perl6 regexes

Angel Faus
August 21, 2002 09:07
Re: imcc hack for perl6 regexes
Message ID:

> 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.


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 "."


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 

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.


-angel Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About