IMCC and multiple source files
K Stol
Is it possible to have a program, which consists of multiple IMCC source files?
So, something like this: (pseudo code, don't know IMCC (yet))
-----------------------------------------
/* File #1: */
...
call funcA
...
sub funcB(x)
/* do something */
end sub
...
---------------------------------------
/* File #2 */
...
sub funcA(x)
/* do something */
end sub
...
call funcB(123)
...
-----------------------------------------
So some function defined in File 2 will be called from File 1.
Is this possible? If yes, (how) will this be checked during assembling? Are there some kind of 'header'-like files?
Or, is this only possible directly in Parrot ASM? If so, how is checking done then?
Regards,
Klaas-Jan
Leopold Toetsch
> hello,
>
> Is it possible to have a program, which consists of multiple IMCC source files?
Not yet, directly.
As a workaround, other files can be .include-ed into main, at least from
now on, I have committed a change and a test for this.
> Are there some kind of 'header'-like files?
No header files. The subroutines have to use global labels (with one
underscore in front), like:
.sub _main
bsr _sub1
bsr _sub2
end
.end
.include file1.imc
# file1.imc
.sub _sub1
..
ret
.end
These labels and branches are resolved then (the compilation of such
subs is already separate).
> Regards,
> Klaas-Jan
leo
K Stol
Just 1 more question, for me to get it right.
When I have 2 modules, for example like this:
---main.imc-----------
.sub _main
bsr _hellosub
end
.end
.include hello.imc
----------------------
---hello.imc----------
.sub _hellosub
/* print "hello" or whatever */
ret
.end
-----------------------
The ".include" makes sure that IMCC can resolve the labels and stuff?
Does it work like this: when IMCC sees ".include", it goes looking for
the given file, and just inserts the contents of it into the file that was
being compiled,
in this case, "main.imc". (I mean not really *insert* into the file, but in
IMCC symbol table
or something like that.)
> These labels and branches are resolved then (the compilation of such
> subs is already separate).
Or, can the modules be compiled separately without any error like "missing
label" ?
Klaas-Jan
>
>
> > Regards,
> > Klaas-Jan
>
> leo
>
>
Leopold Toetsch
> Hello,
> Just 1 more question, for me to get it right.
> When I have 2 modules, for example like this:
>
> ---main.imc-----------
> .sub _main
> bsr _hellosub
> end
> .end
> .include hello.imc
> ----------------------
> ---hello.imc----------
> .sub _hellosub
> /* print "hello" or whatever */
> ret
> .end
> -----------------------
>
> The ".include" makes sure that IMCC can resolve the labels and stuff?
Not exactly, the .include just inserts the file in place. It has nothing
to do with fixups. The .include already happens in the lexer.
> .. (I mean not really *insert* into the file, but in
> IMCC symbol table
> or something like that.)
The other way round, the file gets inserted, that's it, no label
resolution or such.
> Or, can the modules be compiled separately without any error like "missing
> label" ?
The 2 subs are compiled independendly. When a PBC file is generated or
when the program should be run, global fixups (like in your example) are
done then. Global label fixup happens after compilation of all
compilation units.
s. docs/parsing.pod
/compilation unit
and t/syn/bsr.t
(the 2 last tests are equivalent, the latter is with .include)
> Klaas-Jan
leo
Joseph F. Ryan
>Hello,
>Just 1 more question, for me to get it right.
>When I have 2 modules, for example like this:
>
>---main.imc-----------
>.sub _main
>bsr _hellosub
>end
>.end
>.include hello.imc
>----------------------
>---hello.imc----------
>.sub _hellosub
>/* print "hello" or whatever */
>ret
>.end
>-----------------------
>
>The ".include" makes sure that IMCC can resolve the labels and stuff?
>Does it work like this: when IMCC sees ".include", it goes looking for
>the given file, and just inserts the contents of it into the file that was
>being compiled,
>in this case, "main.imc". (I mean not really *insert* into the file, but in
>IMCC symbol table
>or something like that.)
>
I'm really curious as to this myself. I didn't even know an
"include" existed; its not in the imcc docs. I only bring this up
because around a month ago, I started working on use/include/inline
semantics for languages/perl6. Then I got mono and I stopped.
However, I'm better now and I'd really like to know of how much I
have is redundant, and if .include can help resolve some of the
symbol name conflicts that I was having.
So, does anyone know? (-:
Joseph F. Ryan
ryan...@osu.edu
Leopold Toetsch
> I'm really curious as to this myself. I didn't even know an
> "include" existed; its not in the imcc docs.
Its in docs/macros.pod, though this file is not mentioned in the main
doca AFAIK.
> ... I only bring this up
> because around a month ago, I started working on use/include/inline
> semantics for languages/perl6. Then I got mono and I stopped.
> However, I'm better now and I'd really like to know of how much I
> have is redundant, and if .include can help resolve some of the
> symbol name conflicts that I was having.
.include doesn't help here. If you have symbol name conflicts (which?)
you can do several things:
1) for variables
- use .namespace
- mangle them
- us uniq names, as P6C does
2) for labels
- global labels have to be uniq (and must start with an underscore)
- local labels have to be uniq per copilation unit and shouldn't have
and underscore in front.
> Joseph F. Ryan
leo
Joseph F. Ryan
> Joseph F. Ryan wrote:
>
>> I'm really curious as to this myself. I didn't even know an
>> "include" existed; its not in the imcc docs.
>
>
>
> Its in docs/macros.pod, though this file is not mentioned in the main
> doca AFAIK.
I don't have a docs/macros.pod. I guess my version of imcc is old (-:
>> ... I only bring this up
>> because around a month ago, I started working on use/include/inline
>> semantics for languages/perl6. Then I got mono and I stopped.
>> However, I'm better now and I'd really like to know of how much I
>> have is redundant, and if .include can help resolve some of the
>> symbol name conflicts that I was having.
>
>
>
> .include doesn't help here. If you have symbol name conflicts (which?)
For instance, in the interests of speed, it would be nice if perl6
builtins written in perl6 would be pre-compiled to imcc, so that
they could just be tacked on at the end of the .imcc file (or even
.include-d, now that I know about that.) However, if these are
precompiled, then their local symbols will numbered starting at the
same place (for instance, L_1, L_2, etc), and you get a conflict
when this file is included. So, I had to mangle.
> you can do several things:
>
> 1) for variables
> - use .namespace
This seems like it will really help; one question I have is:
Does .namespace work with .subs? As in, does it help
support "local subs?" Or is this wishful thinking?
> - mangle them
> - us uniq names, as P6C does
I'm using these 2 methods to avoid conflicts now. Maybe I can take
out much of the mangling with the help of .namespace.
Thanks for the reply,
Joseph F. Ryan
ryan...@osu.edu
Leopold Toetsch
> Leopold Toetsch wrote:
>
> I don't have a docs/macros.pod. I guess my version of imcc is old (-:
The update your parrot please. A lot of these issues are documented and
solved.
> For instance, in the interests of speed, it would be nice if perl6
> builtins written in perl6 would be pre-compiled to imcc, so that
> they could just be tacked on at the end of the .imcc file (or even
> .include-d, now that I know about that.)
Librarys will do it. S. the articles on multiple code segments.
> ... However, if these are
> precompiled, then their local symbols will numbered starting at the
> same place (for instance, L_1, L_2, etc), and you get a conflict
> when this file is included. So, I had to mangle.
No, as documentation states, local labels of one sub don't interfer with
local labels of another sub.
>> 1) for variables
>> - use .namespace
>
> Does .namespace work with .subs? As in, does it help
> support "local subs?" Or is this wishful thinking?
Wih subs, even locals ones and nested scopes. Please read the docs and
have a look at the test dir for examples.
> Thanks for the reply,
>
> Joseph F. Ryan
leo