Peter Kuschnerus
2013-07-27 14:38:12 UTC
Hi all
After working several months with the same snapshot,
I rebased to a newer current version.
Then I found some incompatibilities.
I use the routine myormake to convert
indexing and auto-increment to special addressing-modes.
In the past post-increment was expressed by (x += 1) - 1
now it is expressed by (t = x, x++, t)
The old was within one tree.
The new is separated into three trees.
The routine myormake uses the macro R2PACK
to pack the information into n_rval for further use.
This packing needs regs but not temps.
As myormake is called before otimizing and again after ngenregs,
only the later call can do this packing.
In the past it worked as expected.
Trying to adapt to the new fails because
myormake gets only one tree as argument.
It cannot see the sequence of trees.
And then because myormake is called from emit,
the other trees are not present, as they are already emitted.
I wonder now how myormake can be adapted to the new style.
Regards
Peter Kuschnerus
After working several months with the same snapshot,
I rebased to a newer current version.
Then I found some incompatibilities.
I use the routine myormake to convert
indexing and auto-increment to special addressing-modes.
In the past post-increment was expressed by (x += 1) - 1
now it is expressed by (t = x, x++, t)
The old was within one tree.
The new is separated into three trees.
The routine myormake uses the macro R2PACK
to pack the information into n_rval for further use.
This packing needs regs but not temps.
As myormake is called before otimizing and again after ngenregs,
only the later call can do this packing.
In the past it worked as expected.
Trying to adapt to the new fails because
myormake gets only one tree as argument.
It cannot see the sequence of trees.
And then because myormake is called from emit,
the other trees are not present, as they are already emitted.
I wonder now how myormake can be adapted to the new style.
Regards
Peter Kuschnerus