>> Since these kind of lines may appear in mass, such optimization >> may result in code size reduction and speed increase. > > Yes, it will give some speed improvement but please remember that > we have limited PCODE list. Such problem does not exist in -gc3 > output because we can use unlimited list of functions and such > code is already optimized. Just look at code generated when -gc3 > is used and hb_xvmArrayItemPush()/hb_xvmArrayItemPop().
Nice, I didn't know it. But, since -gc3 makes code pretty big, and it's not very practical to compile whole app level code with it (I'm getting a 27MB executable - vs. 10.8MB), and it's the app code which holds most of these constructs, at the end, the final app cannot benefit much from it, certainly not size-wise. We still have 75 free pcode slots, I'm not saying to waste them, but if we could give benefit by cleverly adding a few ones, we should IMO do it. If we use them up all in the future, we can make a usage statistics, and convert rarely used, or non-speed/size criticial ones to two bytes. [ Well, such quasi structures are an relatively ugly hack anyway, maybe we should rather think about some sort of record / structure syntax, but that leads very far and I don't know what would be a good way to do it, if at all. ] Some more optimization ideas from the past: SUBSTR(), ASC( SUBSTR() ), RETURN .T., RETURN .F., RETURN NIL Another nice optimization is what Mindaugas wrote in a document: If compiler detects that a given variable was only used with numeric values (assigned constant numeric, and wasn't involved in any other assignments, passed by reference, etc) it can be safely optimized to use native C type with -gc3 output. Such case is typical for loop variables. Loops are often used in generic code, compiler with -gc3, so it looks like to give benefit. --- quote from Mindaugas: "P.S. Here is another thing (not related to virtual machine and pcode evaluation), but pcode tracing allows to find out various things, for example to trace type of variables, or trace usage of constant values. This allows to make constant folding other optimisations (see http://en.wikipedia.org/wiki/Constant_folding). Ex.: FOR nI := 1 TO 50 QOUT(nI) NEXT can be compiled to: int local1; local1 = 1; lab00001: hb_xvmPushFuncSymbol( symbols + 1 ); hb_xvmPushInteger( local1 ); if( hb_xvmDo( 1 ) ) break; local1++; lab00002: fValue = local1 > 50; if( !fValue ) goto lab00001; instead of: hb_xvmPushInteger( 1 ); hb_xvmPushUnRef(); hb_xvmPopLocal( 1 ); goto lab00002; lab00001: ; hb_xvmPushFuncSymbol( symbols + 1 ); hb_xvmPushLocal( 1 ); if( hb_xvmDo( 1 ) ) break; if( hb_xvmLocalIncPush( 1 ) ) break; lab00002: ; if( hb_xvmGreaterThenIntIs( 50, &fValue ) ) break; if( !fValue ) goto lab00001; But perhaps we must wait for type declarations in Harbour instead of trying to guess variable types from pcode." --- Brgds, Viktor _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
