|
Hans, Can we discuss this more, but on the MI list? thanks, Steve -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Hans Sent: Saturday, May 24, 2003 6:38 PM To: rpg400-l@xxxxxxxxxxxx Subject: 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 _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.