SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 22 Apr 2004 08:18:22 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Onward software soldiers

Content Type: text/plain

At the last meeting someone raised the question of converting
existing programs to PL/E, later named to SL/I. I responded
that it would not involve a source to source conversion, but
instead one of an executable to source. In that manner you
needed only one conversion program regardless of the source
language(s) used. In effect to "reverse engineer" or
"disassemble" the executable whether .exe, .sys, or .whatever
to PL/E source.

I use the term "disassemble" because we do have existing
software which converts executables into assembly language.
From my perspective that suffices to use the same process to
convert an executable to PL/E source. It suffices because
Intel conveniently list three forms of each Pentium instruction
in its reference manual: (1) actual, (2) symbolic assembly, and
(3) HLL. Thus we have a one-to-one (1:1) mapping between
an assembly language instruction and an HLL form (take my
word expressible in PL/E).

Bearing in mind that every programming language is also a
specification language, unavoidably so, that means you can
have a mix of machine-independent and -dependent
specifications in the same source. It also means for code
generation to occur at all ultimately every
machine-independent specification, i.e. source statement, must
decompose into a set of one or more machine-dependent
ones.

Thus included in the specifications of the language itself we
have a set which "specifies" this mapping, this decomposition.
In fact we must have a set for every machine instruction set
on which we wish to execute, in that manner provide
cross-system support.

That means the language implementation, that which
processes the source language, needs to distinguish between
machine-independent and -dependent specifications. That
distinction would occur on the data types involved in a source
expression. For example defining a register as:
dcl 1 eax register,
2 ex bit(16),
2 ax,
3 (ah, al) bit(8);

The use then of eax, ex, ax, ah, or al would indicate the
presence of an machine-dependent specification. This means
in essence defining the architecture, at least that referable
within the instruction set, as a set of specifications.

Given we can do that on the basis that Intel has already done
it as well as IBM in at least two instances using APL, the
question of disassembling an executable into a set of
machine-dependent specifications becomes moot. The next
challenge occurs in taking the disassembled
machine-dependent specifications and assembling them into a
machine-independent form.

I would like to address that at some point in the future.
Having had some experience in disassembling PL/I and COBOL
executables into their PL/I and COBOL source for clients who
had "lost" their source, I would like to demonstrate the
process. In that manner also illustrate its automation.

Of course, that assumes sufficient interest in this exists. That
sufficient interest should include also the use of pattern
recognition and how that occurs.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 22 | April | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.