Leopold Toetsch wrote:
> Have a look at imcc, which is our high level assembler. imcc does
> register allocation and (currently little) optimization. perl6 produces
> IMCC code. imcc can also run the code or write PBC files.
Yes, I saw that. I haven't yet decided whether to generate pasm
or imcc directly from cscc. I did have some problems getting
"test_spilling.imc" to work. Is this a known issue?
> > What is the size of the "int" type? Will it always be 32 bit
> > or is it "whatever is best for the machine"?
>
> It's a Configure option.
That may be a bit of a problem, as C# (and Java for that matter)
is very particular about the sizes for its types, and the
behaviour of operations. e.g.
int x = (0x80000000 + 0x80000000) / 2;
This will give 0 on a 32-bit system, but 0x80000000 on a 64-bit.
Note: I'm not criticising Parrot's choice to use native integers.
It just would be nice for a compiler to be able to say "this type
must be n bits because I say so!".
> > And how do
> > I perform a "sign extend" operation?
>
> We currently have only one INTVAL, it should promote to BIGINT.
That's not quite what I was after. Here is an example:
int x = ...;
int y = (short)x;
The value of x is truncated to 16 bits, and then sign-extended
to int. I'm looking for something like the "conv.i2" instruction
in IL, or "i2s" in JVM.
> > Is there some means to store and access auxillary data in
> > a Parrot bytecode file? I might need this to store metadata
> > for supporting C# reflection.
>
> There was some discussion WRT extending the bytecode format not too long
> ago: s. Subject "RFC: static line number information".
I have a suggestion: allow compilers to embed arbitrary extra
"named sections" in the bytecode format. From the point of view
of the Parrot VM, it's just binary data to be ignored. But the
program can do an "open_section" or something to read the data
as a stream. Then it is up to the compiler and the associated
language libraries as to how the data is interpreted. Just a
suggestion.
Cheers,
Rhys.
