On Mon, 08 Jun 2009, Mindaugas Kavaliauskas wrote:
Hi,
> I was thinking about another optimisation.
> hb_vmPush( pValue );
> hb_vmPush( pSelf );
> for( i = 1; i <= iPCount; i++ )
> {
> hb_vmPush( hb_stackItemFromBase( i ) );
> }
> hb_vmProc( ( USHORT ) iPCount );
> Can it be changed to? :
> hb_itemCopy( hb_stackBaseItem(), pValue )
> hb_vmProc( ( USHORT ) iPCount );
> or even:
> // The same without hb_stackNewFrame() call
> hb_itemCopy( hb_stackBaseItem(), pValue )
> HB_VM_EXECUTE( pValue ); // Well, it lacks EG_NOFUNC check
> Are these methods OK? Is it OK to create new stack frame using the same
> symbol, self and locals?
Using hb_vmProc() is not safe but direct HB_VM_EXECUTE() usage will
work as you want.
> Actually, HB_EXECMSG() is doing it. It calls
> hb_vmProc() without re-pushing parameters to stack, and both frames uses
> the same stack area. Is it OK?
Of course it's a hack though it's safe in current implementation.
It's possible that if we change core code then this hack will have to
be updated so such tricks should not be used by 3-rd party code.
In fact we can also add to HB_EXECMSG()
hb_stackBaseItem()->item.asSymbol.paramcnt =
hb_stackBaseItem()->item.asSymbol.paramdeclcnt = 0;
to keep the HVM stack clean and not confuse any code which can be
written to analyze the HVM stack contents. We are using two different
stack frames but the second one is inside parameters which belongs
to the 1-st one.
In the above code using hb_vmProc() fully overloads the 1-st frame so it's
not safe and will cause HVM stack corruption and probably GPF - I haven't
tried to analyze what exact errors can appear in such case.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
