imcc/ directory

[Matt Diephouse]

Now that IMCC is a core part of Parrot, I'd like to see the imcc/
directory go away. I'd be willing to spend some time trying to prepare
some patches (it'd be a good way to become more familiar with the
source), but I have a few questions first:

(1) Is this desirable?
(2) Does IMCC's version number ever differ from Parrot's? Right now
they're both defined, but they're both the same. If they'll always be
the same, it doesn't make sense to have an IMCC version number (IMHO).
(3) Should all the headers in imcc/ be moved to include/parrot/?
(4) Should all the files be moved to src/?
(5) Should the contents of the docs/, examples/, and t/ directories
be moved to the root directories of the same names?
(6) Is there a document i should be reading about Parrot's directory structure?
(7) Should IMCC_ functions stay with that prefix or be renamed to use
Parrot_ or something similar?
(8) Is there any reason to keep src/parrot.c around?
(9) Is there anything else I should be aware of?

Thanks.

--
matt diephouse
http://matt.diephouse.com

[MrJoltCola]

At 06:57 PM 4/11/2005, Matt Diephouse wrote:
>Now that IMCC is a core part of Parrot, I'd like to see the imcc/
>directory go away. I'd be willing to spend some time trying to prepare
>some patches (it'd be a good way to become more familiar with the
>source), but I have a few questions first:
>
> (1) Is this desirable?

Technically IMCC should be separate

I think mild separation that still exists is a good thing. IMCC does
not actually execute anything, it is a "registered" front-end that
handles PIR and PASM. You could add another front-end
called PIR2 if you wanted. It just so happens that IMCC is the
default front-end.

> (3) Should all the headers in imcc/ be moved to include/parrot/?
> (4) Should all the files be moved to src/?

You should be able to build a standalone VM that will run pre-compiled
bytecodes without including the full parser/compiler, IMO. I'd prefer
to see the separation continue.

Regards,

-Melvin

[Bernhard Schmalhofer]

MrJoltCola wrote:
> At 06:57 PM 4/11/2005, Matt Diephouse wrote:
>
>> Now that IMCC is a core part of Parrot, I'd like to see the imcc/
>> directory go away.

> Technically IMCC should be separate

>
> I think mild separation that still exists is a good thing. IMCC does
> not actually execute anything, it is a "registered" front-end that
> handles PIR and PASM. You could add another front-end
> called PIR2 if you wanted. It just so happens that IMCC is the
> default front-end.

Actually there is already a second front end, PAST, which resides in the
'ast/' directory.
It might make sense to refactor 'imcc/main.c' and split it into e.g.
'src/main.c' and 'imcc/frontend.c'. This would make the distinction more
clear, and would provide an opportunity to clean up the exported symbols.

CU, Bernhard

--
**************************************************
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************

[Leopold Toetsch]

Matt Diephouse <mdd...@gmail.com> wrote:
> Now that IMCC is a core part of Parrot, I'd like to see the imcc/
> directory go away. I'd be willing to spend some time trying to prepare
> some patches (it'd be a good way to become more familiar with the
> source), but I have a few questions first:

> (1) Is this desirable?

As Melvin already stated, no: IMCC is a distinct subsystem of parrot
namely the PASM/PIR compilers (or assemblers). If you like to spend time
on it, I'd prefer the following instead:

- split PASM/PIR parsers and lexers into tow distinct file pairs
- make the C<.macro> pre-processor a separate pass

> (2) Does IMCC's version number ever differ from Parrot's?

We probably don't need the IMCC_VERSION.

> (3) Should all the headers in imcc/ be moved to include/parrot/?

No, they are mostly private to IMCC. But we need eventually a public
compiler interface, which should reside inside include/parrot.

> (4) Should all the files be moved to src/?

No with one exception: imcc/sets.c is a file implementing a bit set. All
functions should get a Parrot prefix and an interpreter argument.

> (5) Should the contents of the docs/, examples/, and t/ directories
> be moved to the root directories of the same names?

imcc/examples is useless, it can go away. imcc/docs needs some updates.
Especially syntax.pod sould be pasm.pod and pir.pod. Both are not quite
up-to-date. The tests are for testing the assemblers and should stay
there.

> (6) Is there a document i should be reading about Parrot's directory
> structure?

Probably:
$ perldoc -F docs/pdds/pdd07_codingstd.pod
/Subsystems

> (7) Should IMCC_ functions stay with that prefix or be renamed to use
> Parrot_ or something similar?

The IMCC_ prefix is fine.

> (8) Is there any reason to keep src/parrot.c around?

I'd like that to be eventually the real start program. It should parse
the commandline arguments and select an appropriate compiler depending
on the source filetype. One of these compilers is IMCC (or two :)

> (9) Is there anything else I should be aware of?

Yes ;)

> Thanks.

leo