Anton Ertl wrote:
>
> Anton Ertl wrote:
> > I am currently thinking of the following test to check the validity
> > and completeness of the arrangements of a particular primitive: Take
> > all the labels we have, and sort them. If the labels of one primitive
> > (we have three, one at the start, one near the end, and one at the end
> > just before a superfluous asm statement) are consecutive, without an
> > intervening label of another primitive, then we assume that it is ok,
> > otherwise it is not. I fear this assumption will not be conservative
> > enough for gcc-3.4, but that's the best I can think of right now. Any
> > other ideas?
> >
> > If it is ok, we use the start and end labels as suggested by Matthias.
>
> I have now implemented a variation of this idea: Instead of requiring
> that the primitive ends in its own end label, any end label will do.
I have now implemented a slightly different scheme: Search for the end
label that is next after the start label to find the end of a
primitive. Then check if the near-the-end label is between them (it
should be, otherwise report a negative). I hoped that this would have
fewer false negatives than the earlier scheme; I don't expect it to
have more false positives. In any case, for gforth-fast with gcc-3.3
both schemes report the same number of negatives (false or not). I'll
stick with the newer scheme, as it seems conceptually simpler.
On false positives: I currently don't see a way to get a
reported-relocatable primitive that is not relocatable (at least not
with our address/length information) with this scheme:
gcc would have to move a piece of code of the primitive to before the
start label or behind the end without getting one of the
as,("")/SKIP16 in between (if it gets a skip, the comparison with
engine2 will catch the non-relocatability of the branch to the moved
code).
a) It cannot move stuff right before the start label without getting
such a skip, because the skip looks like falling through to the start
label (ok, gcc could introduce a jump around the moved stuff, but
let's hope it does not become that perverse).
b) If it moves stuff behind without getting such a skip, the stuff
will be before any end label (the skip is the first thing after the
end label), and thus will be included in the total length for the
primitive.
There is a possibility that gcc could move code between the
near-the-end-label and the end label. Then --dynamic --nosuper would
work, but --dynamic would not (for superinstructions the code between
the near-the-end label and the end label is not always copied). One
way to eliminate this danger is probably to put a skip right after the
near-the-end label. However, this may lead to more false negatives,
so I won't do this until we get this problem.
Any fault with this analysis?
- anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
