Erm, my statement was actually just an assumption that the first op
would be a 'saveall' -- I haven't looked at actual imcc output.
imcc does not emit any additional instructions currently. This is why I did start this thread in the first place.
- imcc takes the code produced by $HL compiler *as is* and
- has to figure out, what $HL actually wants to do (WRT CFG and data flow)
Currently imcc checks the first few instructions of a subroutine. If a saveall is found imcc assumes, that there is no inofficial (via registers) data flow into the sub or back.
If no saveall is found, imcc assumes that data are passed in registers and accounts in the CFG for this.
This is all fine, to make it assemble and run the *hand crafted* test cases. But this is not the way to go (IMHO) for using imcc as a compiler for another HL.
I would like to have nailed down the calling conventions and I would like to have hints in imcc's input file, that state we gonna call this sub and caller saves or callee saves, or use PDD03 ...
Please imagine something like this:
_main:
$P0 = new Sub
$P1 = new PerlArray
...
many set_addr
...
$P0 = $P1[$I99]
invoke $P0
ret
_sub1: ...
_sub2: ...
_sub3: ...The address, where the invoke branches to is calculated somehow then goes into an array (or may be passed from another sub) and can be anywhere. When imcc has no assumptions about calling conventions, it has to consider each label as possible branch target and has to follow the data flow.
This will typically lead to a lot of spilling due to the register allocator running out of free registers.
OTOH with known calling conventions imcc could optimize a few simple leafs in the call chain (of procedural code) and e.g. reorganize registers so that pushx/saveall/popx... are just thrown away.
leo
