|
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
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.