Re: imcc/ directory
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: [EMAIL PROTECTED] Website: www.biomax.com **
Re: imcc/ directory
Matt Diephouse [EMAIL PROTECTED] 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
imcc/ directory
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
Re: imcc/ directory
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
