RE: VARPG Codegen (was threading in rpg)

Steve Richter wrote:
>>Yes. Much lower level. Think of loads and stores. The fact that W-Code is
>>much lower level than MI is one of the reasons it can be optimized much
>>more aggressiveley.
> 
> Wait a minute!  Wouldnt it be that the more the optimizer knows about the
> task that is to be performed, the better it will be able produce well
> optimized code?  For example, cant the copy of one data struct to another
> be optimized better than a long series of w-code load and store
> instructions? When copying the data structs, the optimizer can determine
> that only the packed decimal flds have to be copied individually while the
> char and int
> flds can be strung together as a single bit blt type instruction.  And the
> copy of the packed flds can possibly be done in parallel.
> 

Good question. An MI compiler could optimize the code generated for one MI 
instruction. Sure, some optimizations were done with MI, but in practice 
the optimizations were not very aggressive. The really good optimizations 
are those that cross statement boundaries. Optimizations such as code 
motion and common sub-expression analysis benefit from an intermediate 
language specifically designed for aggressive optimizations.

>>And that's what the W-Code would look like if A and B had the same numeric
>>datatypes. With mixed types, you'd also have to throw in the data
>>conversions, which gets really messy when you get to character values. A
>>simple CPYBLA(P) MI would expand to dozens of W-Code instructions. So in
>>reality, this simple example makes W-Code look nicer than it really is.
>>W-Code was designed to be generated by compilers, not to be programmed by
>>humans.
> 
> Interesting to know, but it sounds like a waste of the compiler writers
> time. Shouldnt the RPG compiler writer be dealing with issues like
> database file io, varying string fields and mult occur data structures
> then reinventing the translation of "a = b" to w-code wheel?
> 
> In my opinion, the wizards who invented the S/38 were more on track to
> common sense hardward independence and efficient HLL translation to
> machine code with the relatively high level MI.

Regarding database I/O, that's implemented in C code in a run-time library, 
and that really is the same regardless of the intermediate language.

The whole idea of MI was to make it easier for an RPG compiler to generate 
good code, and to a great extent it succeeded. Unfortunately, MI didn't 
match RPG semantics exactly in all circumstances. So while for the most 
part most RPG statements resulted in a few MI statements, in some 
degenerate cases, the code expansion was awesome, with correspondingly poor 
run-time performance.

In addition, while MI matched RPG semantics fairly well, COBOL was a less 
good match, and C was a horrible match. And so, other languages were 
severely hobbled.

So in a sense, what seemed like "common sense" to the original designers of 
the S/38, in practice really doesn't work all that well.

In many ways, the W-Code approach makes things easier for compiler writers. 
Since you have to build up an operation from lower level pieces, you're 
forced to modularize the compiler much better. And so, most code gen 
happens in common service functions, such as "genload()" and "genstore()". 
These common service functions handle all the nitty gritty details of 
different data types and shapes. In practice, this actually makes working 
with the compiler much easier.

Cheers! Hans