RE: VARPG Codegen (was threading in rpg)

Steve: You suffer from several misunderstandings on the subject, so I may 
have to address each statement individually to try to make the issues 
clear.

Steve Richter wrote:
> Is W-Code lower level than MI?  

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.

> An MI to C translator would only have
> problems with the hardware specific items like exception handling, CALLX,
> BASPCO.  I would assume that w-code is mi without the OS dependent
> opcodes. 

Yes, MI has a few opcodes that are specific to the iSeries, and to some 
extent is intimately tied to the O/S. But W-Code is *not* MI without the 
O/S dependent opcodes. It is very much different. Knowledge of MI will help 
you not at all when learning W-Code. W-Code is much more like a machine 
language, such as 68000 machine code. Or think of the 80x86 architecture 
without the registers.

> The MI CPYNV, CPYBLA, CPYBLAP, SUB, ADD have one to one
> equivalents in C. 

Only in the sense that MI opcodes can be invoked by functions that implement 
MI opcodes directly. As implied earlier, MI is a fairly high-level 
intermediate language.

> Did W-Code do away with compare and branch of MI and
> replace with a nested
> IF .... End pair?  

Think low-level operations, like TJP and FJP (jump if true, jump if false 
respectively). That is, you push a logical value on the stack, and branch 
based on that value. Just like many low-level CPU architectures.

For example, where you'd have a "CMPNV A,B/EQ(LAB1)LT(LAB2);" instruction in 
MI, you'd have something in W-Code that would look like:

LOD A
LOD B
EQU
TJP LAB1
LOD A
LOD B
LES
TJP LAB2

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. 

> I am sure the great, programmer friendly data pointer
> was killed!

Correct.

> 
> C is pretty flexible in that it provides all the primitive data types +
> function calls and scoping.  So I will stand by my assertion that it would
> be worthwhile to have C as a common denominator option because of the
> availablity of the C compiler on all platforms.

And you would be wrong. 

> 
> Is there a W-Code to linux capable executable translator separate from the
> W-Code to windows executable translator.  If so, wouldnt a single W-Code
> to C translator obviate the need for a w-code translator for each target
> platform?

Huh? Like I said before, Linux is an operating system kernel, not a machine 
architecture. There is nothing in W-Code where it has to have any knowledge 
whatsoever about the O/S kernel the resulting program runs under.

> 
> So, the technical question is, what is the difference between C and
> W-Code?

What's the difference? One's a high-level programming language commonly used 
for systems programming. The other's a low-level intermediate language used 
by IBM compilers. It's like comparing apples and motorboats.

Cheers! Hans