This chapter introduces the second theoretical foundation that covers code-translation, modular-programming, and encapsulation. The theory of code-translation is useful to understand the scope of dissertation: that the proposed orthogonality theory is limited to source-code, and the difference between code-translator from programming-language. Theory of modular programming and encapsulation is needed to understand the orthogonal module-based encapsulation in chapter 5.
Code-translation is often called translation in textbooks like [2, 38]. We add the prefix code- to emphasis that the translation is about the translation of code in computer programming. Subsec 3.1.2 lists the kinds of code that are translated.
3.1.1 Model of processing
The model of Input-Process-Output is well known across all disciplines. In the simplest processing, we can say that the input is raw-material, and the ouput is ready-to-use product. Figure 3.1 illustrates the simple model.
However, in the practice of many engineering there are many processes. In the presence of many processes, an output of one process may be an input for another process. The thing that is being output of one process and input for another can neither be the raw material not be the ready-to-use-product.
Hence the concept of half-baked product. It is an output of some process, and the input for another. Figure 3.2 illustrates this model, that is slightly more complex than the one in fig 3.1.
Figure 3.1 Simple Processing
Figure 3.2 Complex Processing
3.1.2 Forms of software
There are literally thousands of variations in the production process of virtually all products known to human. IPO models for production of software are very simple due to the presence only three forms of software depicted in Table 3.1. Virtually all software are initiated in the form of source-code, the first and initial form of software. Source-code is analogous to raw material . Encoding for source-code is text, while encoding for intermediate-code and runnable code is nontext. Information in text encoding is human readable, and the nontext is not.
|Form of software||Analogy||Encoding|
|Intermediate-code||Half-baked product||Nontext (Binary·)|
|Runnable-code||Ready-to-use Product||Nontext (Binary·)|
Table 3.1: Three forms of software
The second form of software is intermediate-code (also called object-code and byte-code). It is analogous to half-baked product. The encoding is ‘nontext‘, make it incomprehensible for most human.
The third form of software is runnable-code; analogous to finished, ready-to-use product. The encoding for runnable-code is also nontext. The term run is synonymous with execute; and executable-code with runnable-code. Figure 3.3 through 3.5 show analogies of source-code, intermediate-code, and runnable-code. Next section describes the process of producing half-baked and finished product.
Figure 3.3 Raw material for metal cars, analogous to source-code
Figure 3.4 Half-baked product; analogous to intermediate-code
Figure 3.5 Ready-to-use product; analogous to runnable-code
In producing the cars, ballpoints, computer hardware, etc there are various processes performed, each with its own name; many are company-dependent. But there are only few well-defined and company-independent processes in producing the software from one form to another. The process is code-translate. There are only seven variations of code-translate as follows:
- Compile: translate source-code to materialiazed intermediate-code.
- Interpret: translate source-code to unmaterialiazed runnable-code.
- Link: translate intermediate-code to materialized runnable-code
- CompileLink: translate source-code to materialized runnable-code
- LinkRun: translate intermediate-code to unmaterialized runnable-code
- Disassemble: translate from
- Materialized runnable-code to materialized source-code.
- Materialized intermediate-code to materialized source-code.
- translate source-code to source-code.
- translate intermediate-code to intermediate-code.
- translate runnable-code to runnable-code.
Following the latest paragraph in subsection 3.1.1, the Compile and Link will be explained now as two representative code-translate process/operation. Figure 3.6 shows the process compile. To compile a source-code means to produce half-baked product from raw material.
Figure 3.7 shows the process link. To link one-or-more intermediate-code means to produce finished (ready-to-use) product from half-baked products. Note: Many current products use the term Build instead of Link. Build means compile all source-code modules then link all intermediate-code modules.
Figure 3.6 Compiling a source-code
Figure 3.7 Linking an intermediate-code
Figure 3.8 Conceptually java runnable-code program file is linker-runner
The approach of LinkRun is used by Java code-translator if programming-tools such as NetBeans are not used. Figure 3.5 shows an example of Compile and LinkRun. Oracle name the compile process as javac, and LinkRun as java.
Figure 3.9 Code-translation approach in Visual BASIC
The approach of CompileLink is used by Visual BASIC (as shown in fig 3.9). Runnable-code file is produced, but intermediate-code files are not produced. Five out of seven possible code-translate processes are modelled in fig 3.10.
Figure 3.10 Various code-translation approaches
Figure 3.10 illustrates partial set of code-translation approaches. Figure 3.11 illustrates partial list of code-translator, pictured in inverted tree format. In fig 3.10 two approaches are excluded: translate and disassemble. Similarly, in fig 3.11 code-translators performing some approaches of code-translation are excluded. The subsequent paragraphs in this subsection are written to fill the gap.
Figure 3.11 Categories of code-translators
Translating an .EXE file (in Windows or DOS) to source-code files (usually .ASM) is an example of translating materialized runnable-code to materialized source-code. This is a variation of disassemble. But there is another variation: translating the intermediate-code file (e.g., OBJ) to source-code file (.ASM). Translation of materialized intermediate-code into materialized source-code is also called disassemble. In the future scientists may divide these two into delink (translate materialized runnable-code into materialized intermediate-code) and decompile (translate materialized intermediate-code into materialized source-code). Currently both approaches are performed by disassembler.
The word Translator in fig 3.11 should be read as ‘Code-translator’ performing code-translations whose approaches differ from Compiler, Interpreter, Linker, LinkRunner, CompileLinker, and Disassembler. Those approaches cover the translation of source-code to source-code, intermediate-code to intermediate-code, and runnable-code to runnable-code. For simplicity they are grouped into one. Here are the itemized explanations:
- translate source-code to source-code (e.g., Pascal to C, C to Pascal, Transact SQL to PL/SQL, PL/SQL to Transact-SQL, EPS to PostScript, PostScript to EPS).
- translate intermediate-code to intermediate-code (e.g., upgrading TPU Pascal 4.0 to TPU Pascal 5.0)
- translate runnable-code to runnable-code (e.g., running Windows runnable-code on top of Linux Operating-System, converting runnable-code in one format to another)
Code-translator is intertwined closely with programming-language, but they are different things. Sec 3.2 explains the difference to benefits the readers, to understand that the primary byproduct of this dissertation is NUSA programming-language. NUSA code-translator is the secondary byproduct.