imcc versus parrot assembler - and general documentation question
Zellyn Hunter
I was wondering if someone could give a quick answer on how to think about
imcc and native parrot assembler. Is the intention for most compilers to
target imcc? Almost all the examples I see are .pasm files.
Also, as a general rule, what sort of state is the documentation in CVS in?
Some of the files have pretty old last-modified dates, but it's difficult to
tell whether that's because they're still valid or whether they're outdated.
If someone is familiar enough with parrot to do it easily, it might be
helpful to keep a small meta-documentation document in CVS that describes the
"up-to-dateness" of each of the other pieces of documentation. Descriptions
would be things like "up to date" or "hopelessly out of date (and plainly
wrong)". Just a suggestion.
I apologize if these are faqs - I did a quick scan of the docs in CVS and the
past messages on the newsgroup, and have been meta-lurking (avidly reading
the excellent summaries - including the part Piers wonders if anyone ever
reads) for several months now.
Thanks,
Zellyn Hunter
Juergen Boemmels
> Hi all,
>
> I was wondering if someone could give a quick answer on how to think about
> imcc and native parrot assembler. Is the intention for most compilers to
> target imcc? Almost all the examples I see are .pasm files.
That depends on the compiler writer. Some languages compile to *.pasm,
others to *.imc. I think the great plan is to use imcc as general
purpose compiler backend with a C-API and a parrot-API, but there is
still a way to go.
imcc can compile .pasm files. Just use a name ending in .pasm or
use the -a switch. The positive side effekt of this is that it is
about a factor of 10 faster. (To run the test-suite with imcc use
make test IMCC=languages/imcc/imcc
and you will be impressed how fast the test-suite gets.)
> Also, as a general rule, what sort of state is the documentation in
> CVS in? Some of the files have pretty old last-modified dates, but
> it's difficult to tell whether that's because they're still valid or
> whether they're outdated.
Most of the documentation should be valid. But it is not always
complete.
The main description of the parrot assembly and the bytecode-format
are parrot_assembly.pod and parrotbyte.pod. Sometimes in the future
this should be moved to PDD12 & PDD13. (The placeholders are there for
over a year now).
The documentation of the current assembler is perldoc assemble.pl,
there is not yet an autogenerated pod-file of this.
The documentation of imcc lives in languages/imcc/docs and is also
valid. Other languages I can't tell.
> If someone is familiar enough with parrot
> to do it easily, it might be helpful to keep a small
> meta-documentation document in CVS that describes the
> "up-to-dateness" of each of the other pieces of documentation.
> Descriptions would be things like "up to date" or "hopelessly out of
> date (and plainly wrong)". Just a suggestion.
And how do you know if the Meta-documentation is up-to-date?
I think its better to keep the documentation valid in general, and if
its not possible the outdated documentation itself should get marked.
> I apologize if these are faqs - I did a quick scan of the docs in
> CVS and the past messages on the newsgroup, and have been
> meta-lurking (avidly reading the excellent summaries - including the
> part Piers wonders if anyone ever reads) for several months now.
No its not a FAQ. But to quote from languages/imcc/docs/imcc.pod:
Most documentation files end in B<.c>.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Leopold Toetsch
> Hi all,
> I was wondering if someone could give a quick answer on how to think about
> imcc and native parrot assembler. Is the intention for most compilers to
> target imcc? Almost all the examples I see are .pasm files.
Yes, imcc is the prefered target. Imcc can assemble PASM files as well.
> Also, as a general rule, what sort of state is the documentation in CVS in?
> Some of the files have pretty old last-modified dates,
You can assume, the older the more outdated.
> If someone is familiar enough with parrot to do it easily, it might be
> helpful to keep a small meta-documentation document in CVS that
> describes the "up-to-dateness" of each of the other pieces of
> documentation.
Good idea.
> Thanks,
> Zellyn Hunter
leo
Gopal V
> I was wondering if someone could give a quick answer on how to think about
> imcc and native parrot assembler. Is the intention for most compilers to
> target imcc? Almost all the examples I see are .pasm files.
Speaking as someone who finds register allocation a VERY VERY tough nut
to crack , any compiler writer worth his sanity will pick imcc ... Since
you could generate imcc directly from an AST (using triples, converted
to matching temporaries) and still get an optimised pasm output ...
> would be things like "up to date" or "hopelessly out of date (and plainly
> wrong)". Just a suggestion.
Hehe, I think you mean a TODO list for documentation :-)
> the excellent summaries - including the part Piers wonders if anyone ever
> reads) for several months now.
Same here , though I snap out when the list touches objects and parrot..
Gopal
--
The difference between insanity and genius is measured by success
Jerome Quelin
> any compiler writer worth his sanity will pick imcc
And guess which language the Ook! compiler targets? :-)
Jerome
--
jqu...@mongueurs.net
Sean O'Rourke
> Gopal V wrote:
> > any compiler writer worth his sanity will pick imcc
>
> And guess which language the Ook! compiler targets? :-)
Befunge?
/s