REXXwish number 1
Dis-assembly made easy
One thing common to all computer languages is that they work only in one direction; you write the source version, and translate it to machine code (or that step happens when you actually run an interpreted program). Going from an executable back to the source code is not really doable. Some people can read core dumps, but not many. So where does REXX enter? Consider Java, byte-codes, the Java DVM, and that byte-codes are not machine-code, but an intermediate way to specify computer instructions; one needs the DVM to translate byte-code to machine code. NetRexx creates the same byte-codes, and can use the same DVM. But Java and NetRexx are most certainly different languages!
NetRexx is very readable and easily understandable, right? So what do you do when you get a program written in Java, but don't know Java from American "instant coffee"? Translate Java to NetRexx, right? So create the byte-code for the Java version, and "dis-assemble" it into NetRexx. Great! But not - yet - possible. (sigh) Mike Cowlishaw (NetRexx's author) revealed in email he'd also seen the possibilities of such a dis-assembler. I got an impression (very vague) that it might be tackled seriously - someday. But don't hold your breath; we want you to read a few more issues of this newsletter first...
But let's take the dis-assembly concept a bit further. Wouldn't REXX users benefit from being able to dis-assemble a compiled version of some Fortran program into REXX, fix a bug or put in some enhancement, recompile it, and then run it? Without having to shake heaven and earth to get hold of the source code, AND need to rewrite the whole thing into REXX? If we could do this, the whole Y2K scare would be history... Or this neat little utility does almost what you want, but was written in C++. OK, translate the C++ version to byte-code, and disassemble that to classic REXX. Make your changes and test-drive it, then do the REXX --> byte-code --> C++ thing, and mail the new version to the author of the program. In the language *she* understands!
Of course making it possible for such translations from one computer language to any other is a piece of cake, something any casual programmer can do overnight with her eyes closed. All it takes to set this up is:
As I said, one over-nighter, including documentation. Yeah... Right...
For Java and NetRexx, step (1) already exists; the byte-code concept. Step (2) has been done too; we can write programs in Java and NetRexx that can result in the same byte-code. The Java DVM is the implementation of step (4), so we only need to implement steps (3) and (5). Not an easy task. But tell a programmer "it can't be done", and he'll prove you wrong before you can blink an eye!
"Neutral-code" also means an increase in portability in more than just one way:
Translators from source code to "neutral code" may be easier to design than the current full-blown interpreters and compilers. Same for the step from "neutral code" to machine code. And translating from "neutral code" - a standardized halfway step by definition - to a source language should in principle also be easier than going the full route in one shot. Same when going from machine code to standardized "neutral code".
Positive sides galore! Now a few negatives:
Please send your thoughts, using the subject line: