On Wed, 21 Aug 2002 18:02:51 +0200 Angel Faus <afaus@corp.vlex.com> wrote: >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. Ok, then this point is settled. >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", No. :) c) imcc becomes a "middle" level language. I never meant it to be an assembler. In practice intermediate languages provide other constructs such as aggregate type definition that are not available in the assembler. type i : packed int[32] type r : record { foo : int, bar : string } This is not assembler. This is medium level computer language in my book. You could even see things like ..pragma classes_are_hashes or something that would tell the compiler that aggregates should be implemented as standard "Perl" hashes in this piece of code, whereas others might want "packed" aggregates with no runtime introspection capability. >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. But I'm willing to invent and develop another language. And it should be a lot richer than just an assembler with a register allocator and spiller. :) >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. But that was my whole reason for writing it in the first place. I did not want to target the assembler directly. -MelvinThread Previous | Thread Next