Melvin Smith wrote:
> Sean, I'm replying publicly because I'd like to hear other opinions than
> mine, yours, Angel's and Leopold's.
I'll answer here to Melvin's mail, but I'll try to make a summary of all
point's taken in this thread + some more.
> I still prefer infix notation to prefix notation for an intermediate
> language.
The current infix notation is fine. It makes intermediate code, and
perl6 IMCC code generation more readable.
Sean (IMHO) is not trying to give it up.
But:
- infix notation (and imcc internals) are currently limited to
4 registers per instruction, so what about:
$S0 = _AV_a1[$I0;$I1;$I2]
(which - with the key patch - is now working in .pasm)
- imcc.y implements currently a very small (but common) subset of
.pasm instructions. Sean was working on rx-ops, so he needed a
solution to get them through imcc, including register allocation,
so his patch is a nice thing to have _arbitrary_ ops in imcc.
- currently, imcc register allocation is br0ken[1]. I tried hard today
to find _some_ of the bugs, but did not succeed finally - til now ;-)
[1] some internals, as Steve mentioned, such discussions should be more
public:
o in cfg:spill() the branch flags in ->type are not copied ...
emitb( mk_instruction(tmp->fmt, r0, r1, r2, r3, tmp->flags) );
+ instructions[n_instructions - 1]->type = old_instructions[i]->type;
.... so after spilling there was/is only one basic_block.
o symregs->first and ->last are off by one compared to life_info's.
o memory allocation/freeing is a mess:
e.g. it seems that a symreg->fmt get's corrupted
sprintf(buf, "%c%d", reglist[x]->set, reglist[x]->color);
in cfg:try_allocate() helps. (reglist is from my tries = ..graph[x])
I did not succeed finally:
PC=90; OP=108 (set_i_p_ki); ARGS=(I0=2, P0=0x8059068, [I1=0])
Subscript on something that's not an aggregate!
So please, first, let's consider the status quo, not the future.
Above error is from perl6's test 3_2.p6. Simplifying the test by one
line (and thus using less registers, helps aka let it succeed). So the
problem is definitely imcc's register allocation and spilling.
Angel, Melvin, if there are any patches, check them in _early_^Wnow -
please.
> I don't understand why it is so hard to adopt. imcc is supposed to be
> a step closer to higher level languages, which is why I went that way.
No problem here, it is called _intermediate_ ..., which is a worthful
step in code generation, but - as always - there is a but, it should
supply the infrastructure to generate _all_ possible .pasm code.
Concluding:
_SV_s1 = clone $P1
$S3 = _SV_s1
$I4 = 0
goto L_startre4
L_advance5:
rx_advance $S3, $I4, L_rx_fail6
contains imcc language elements (infix) + pure pasm ops, which get
looked up via core.ops aka libparrot.so, but profit from register
allocation.
> What I have heard is, "Why make imcc use a different syntax, it requires
> people to learn a Parrot assembler _and_ imcc."
Melvin, Sean's patch is not agaist imcc's syntax, it _extends_ the
syntax with badly needed pasm syntax. There a currently 261 basic ops
variating to a total of 844 different ops, why should imcc all implement
_all_ and still permanently changing ops mow.
I personally like imcc's syntax, it's a lot more readable compared to pasm.
> I'm still for what we talked about, where any imcc directive uses a
> leading '.'
> and the rest of the ops are passed through; with the primary exemption
> being those ops like set, add, etc. that have more common infix version
> like:
>
> a = 1
> b = a + 1
So, finally, we all concede :-)
Let's keep the high level infix instructions for the most common ops and
unknown ops should be looked up dynamically. Of course, register
allocation is still done for these.
> -Melvin
Thanks for reading til here,
leo
