n_add Px, Py, 1 n_abs Px, Py
These opcodes can/should be used by HLLs like Python, which have the semantics of immutable scalars and newly created result PMCs.
2) Tests for all these opcodes are very welcome
3) Proposal: PIR syntax enhancement
.pragma n_operators ... Px = Py + 1 ... [EOF]
Within this pragma (valid inside and until end of file) the shortcuts '+', '-', ... should translate to "n_add", "n_sub", ...
This simplifies the adaption of already existing compiler code and is a bit more readable.
4) HLL to Parrot core type mappings.
Most of Parrot's core classes functionality can now be inherited by HLL-specific classes. But there are still some explicit type enums in classes/*.pmc that should be HLL-dependent. E.g.
Complex.absolute()
result = pmc_new(.. enum_class_Float)This should rather be a TclFloat, PyFloat, whatever. To achieve this, we'd need a mapping for core PMCs and an HLL language specifier.
E.g.:
# file1 .HLL python python_group # language, shared lib .type_map Float => PyFloat .type_map Integer => PyInt ...
# file2 .HLL tcl tcl_group .type_map Float => TclFloat .type_map Integer => TclInt
The C<.type_map> has to be specified just once. The C<.HLL> in each source file. If no C<.HLL> was seen, the language defaults to parrot.
Instead of the bare words, we could demand quoted strings too.
Comments welcome, leo
