Conference turris::languages

    I have dabbled with such in my hacking.  The assembly code was
    uncommented, generated by a disassembler.  My experience is limited to
    simple systems and text based applications.
    
    My approach has been to use a text editor to simply replace common
    instruction sequences with macros which generate them.  If the names
    are suggestive, then you may be able to build ever more complex
    sequences of instructions and macros.  Clearly, this will be a
    recursive process.  Deciding when to stop may be difficult.
    
    I have never finished such a project (in the sense of generating higher
    level code).  That may be a reflection on me rather than on the method,
    however.  
    
    Many years ago I did the opposite - I defined Fortran and Algol
    equivalent control macros.  I had to use macros which defined macros to
    get the effects I wanted, so obviously, it can't be all mechanical.
    
    Best of luck,
    
    Dick

There was an advanced development effort within VMS to explore translating
VAX MACRO to C.  Before the worked stopped (at the end of 1990), several
documents were produced:

1. an annotated bibliography on material gathered from literature searches
2. a report documenting a method to identify high-level language control
   structures in VAX MACRO routines
3. a report on the DISASSEM disassembly tool that generates a C file from
   a VAX BSD 4.2 UNIX object module

Contact Christopher Kaler or Cheryl Wiecek for more information.

From:	SHIPS::WINN_G "Geoff Winn @ SBP F9/1, DTN 782 2367  21-Jan-1992 1542"   
21-JAN-1992 11:13:14.69
To:	STAR::KALER
CC:	WINN_G
Subj:	VAX Macro Translation

Christopher,

  	Hi. My name is Geoff Winn. Tom Welsh asked me to contact you regarding
  tools to automatically translate Macro-32 to something else. First of all,
  my apologies for the delay - I've only recently been involved in this.

  	I believe Tom has mentioned to you the Centre for Software
  Maintenance at the University of Durham. I don't currently have any
  paperwork that I could forward to you, however, I have discussed their work
  with them and I include a summary below. We believe that their work has some
  major possibilities and basically we are looking for groups within Digital
  that might be in a position to support some kind of joint venture.

  Summary.

  	CSM have defined a language called WSL (for Wide Spectrum Language)
  which can represent many different levels of program description from
  extremely low level (assembler) to very high level (abstract
  specifications). This is the centrepiece of their translation tool.

  	They currently have a prototype which will read IBM 370 assembler and
  convert it into the equivalent low level WSL statements. They then apply a
  series of transformations (automatically) which extract higher level
  abstractions from the low level statements. These transformations are ones
  which _provably_ retain the same behaviour. Therefore the high level
  statements which they derive are provably equivalent to the original code.
  They currently have enough transformations to get up to the level of a
  reasonable high level language (say C or Pascal), and they are adding more
  all the time. They describe this as extracting (or even "untangling") the
  structure that was implicit in the original code. Their ultimate aim is to
  extract an abstract specification for the original code in a formal language
  like Z.

  	Once they have converted the assembler to pseudo-HLL the user then has
  the option to apply more transformations by hand if they wish. At this point
  the WSL representation of the program is in a state where it is
  comparatively easy to target common high level languages. They have also
  re-targetted assembler. This sounds odd, but what they did was read 370 asm,
  extract the structure and then generate equivalent, but structured asm. This
  allowed them to confirm that they really had preserved the same behaviour.

  Options.

  	I discussed several options with them.

  1. Read in someone else's COBOL and generate VAX/DEC/ANSI C (or whatever).
  This would be worth buckets of money to the field organisation. They aren't
  enthusiastic, mainly because they know nothing about COBOL and have no plans
  to learn.

  2. Read VAX assembler and generate something else (you tell me). They think
  this would be fairly straightforward. They would need help generating a
  parser for Macro-32 but I assume we (Digital) can do that easily enough.
  Assuming you like this idea what do we do now?

  3. Read Bliss and generate C or C++. Same as above except they need help
  with reading Bliss. (They know no more about Bliss than they do about COBOL.
  The difference is they are willing to learn Bliss!)

  	Is any of this interesting? If so, where do you want to go from here?

  	Geoff.

  PS: I didn't explain where I come from! I work for a UK technical consulting
  group called the Product and Technology Group. Tom talked to me about CSM
  because he knew I as interested in formal languages such as Z and thought I
  might be better placed to talk to the people involved. I'm not sure that's
  true but anyway here I am.

re: .3

Interesting.  I wonder how useful such a Z specification could be.

One of the purposes of formal specifications is to present just the
relevant detail, omitting the implementation artifacts.  But the assembly
code must have full details.  Do you really want a specification that
described how the stack grows and shrinks?  Or one that says that "if the
input matches this condition, then this output is produced" (where the output
is an error message or an abort), when what you really want to say is that
the client is obligated to provide input that doesn't match that condition?

I think we could easily derive function headers, globals clauses, and
modifies clauses for Larch/DECspec specifications of existing C code;
we'd have a much more difficult time deriving requires and ensures
clauses that would be useful.

   Gary

>  1. Read in someone else's COBOL and generate VAX/DEC/ANSI C (or whatever).
>  This would be worth buckets of money to the field organisation. They aren't
>  enthusiastic, mainly because they know nothing about COBOL and have no plans
>  to learn.

  There's at least one tool already on the market that does this.  The
  resulting C code is at best 'barely' maintainable, because  C and
  COBOL have completely different datatype support.  Most 'dusty deck' 
  COBOL applications extensively use BCD data - coding for such datatypes
  in C is a real mess because it involves lots of RTL calls, etc.
  Perhaps C++'s abstract types and overloadable operators provide some help
  here, but I still think the result is at best a hack.

  The tool I saw was only useful as a precompiler for a C 'back end'.  There
  was no way that you could easily modify or maintain the C sources after they
  came out of the translator.

Re .4:

>I think we could easily derive function headers, globals clauses, and
>modifies clauses for Larch/DECspec specifications of existing C code;
>we'd have a much more difficult time deriving requires and ensures
>clauses that would be useful.

There's probably demand for even the simplest such derivations.  I say that
because there's demand in the VAXC conference for tools to construct .h files
of ANSI C function prototypes from .c files of ANSI C function definitions.
There's even demand for tools to convert old-style C function definitions to
ANSI C function definitions.

Better a user should have to add their own preconditions and postconditions to
machine-derived global data flow declarations, than that they should have to
derive *both* of them by hand.


Re .5:

>Most 'dusty deck' 
>  COBOL applications extensively use BCD data - coding for such datatypes
>  in C is a real mess because it involves lots of RTL calls, etc.
>  Perhaps C++'s abstract types and overloadable operators provide some help
>  here, but I still think the result is at best a hack.

It's a *goal* of the C++ language for end-users to be able to add new datatypes
like BCD or dynamic strings and make it appear as if it could have been
built-in (and have halfway decent performance).  Whether a particular
application author does a good job (or the language really aids the process) is
one thing, but the potential to do a good job seems to be there to a greater
degree than in any other widespread language right now.
				/AHM

What Craig said about maintainability, but for more general reasons that
datatypes.  Every once in a while, someone in management comes up with
the notion that "all we need" to port masses of BLISS code to new platforms
is a BLISS-to-C converter.  There have been vendors who've promised that
they can do this.  When asked whether the C will be maintainable, they
get very quiet.

I believe that if two languages are very similar, it's possible to
automatically convert from one to the other, but if they're even as
far apart as BLISS and C (which isn't all that far apart), the resulting
code will be unreadable.

While researching 3rd party tools and services I came across one company
who claims to have the capability to convert VAX MACRO to an HLL by
their software tool XTRAN.  In fact they claim to be able do the more
general case of converting source A to target B.

I have not actually tried them so I can not comment on what their
capability is nor what limitations or restrictions there are for the
tool nor what the quality of the converted code is.

It maybe that the tool is not perfect but perhaps it can do enough to
make it worth while.

The company and address is

	Pennington Systems Inc.
	65 South Main Street
	Pennington, New Jersey 08534
	Phone (609) 737-2727
	Fax   (609) 737-2728

    re .6:
    
>one thing, but the potential to do a good job seems to be there to a greater
>degree than in any other widespread language right now.
    
    That's exactly why we're using C++ for something like this right
    now...