Conference turris::languages

Never heard of one.

This company has such a tremendous investment in software written in BLISS at
this point that I think it is likely that there will be a BLISS compiler
for any new hardware platforms that DEC releases.  The big transportability
barrier usually is operating system dependencies, and no automated translator
is going to help with that.  I would put my effort into isolating and
minimizing operating system dependencies in the code, rather than translating
it into another language.

--PSW

A Bliss-to-C translator designed by a succession of 3rd parties in Pittsburgh
has been discussed several times in at least one other conference (TLE::VAXC(?),
q.v.)  At the time DEC looked at it for PDP-10 migration, the results were not
pretty - it stripped comments and inserted lots of unexpected casts.  I presume
the vendor has improved it on since then, but I don't know what the results
were.

New projects should, as always, choose implementation languages which exist for
for all targetted environments.  Existing projects should communicate new
environment requirements to the groups for the products they want to use,
whether they are languages, tools, or runtime facilities.
				/AHM

Re: .0

There exist various companies that sell conversion services.  These
companies have tools that automate the process of translating one
programming language to another.  Usually these companies sell the
conversion service:  they contract to port a software system, use
their tools to do as much of the port as possible automatically, then
finish up by hand.  They deliver the ported program; they keep the
porting tools for themselves--the customer never sees that code!

TLE is evaluating some of these companies and their tools to see if
Digital could and should perform a translation of its BLISS code to
C.  Nothing may come of all of this, but then again...

    As was pointed out in .1, because of the amount of DIGITAL's software
    already written in BLISS, another (in my opinion, more reasonable)
    approach would be creating a new BLISS compiler for whatever new
    environment we wish to target.  The note also highlights the critical
    issue of operating system/processor dependencies in the code itself.
    Simply performing a textual conversion from BLISS to C is not enough,
    even if it can be done satisfactorily, and I would argue that such
    simple textual conversion is the smallest part of any conversion
    effort.  (For at least some applications, the primarily computational
    parts of the application might be reasonably translated;  I don't
    expect many of our applications to be largely computational.)
    
    Even if you have a BLISS-OSF compiler, what about all of the system
    service calls?  How much do you use ASTs or depend upon event flags?
    How about condition handling?  All of these will radically affect
    your software architecture;  you may very well need to redesign
    to achieve acceptable performance, regardless.  I've seen too many
    people do "ports" from U**x to VMS without a redesign, and those
    simple ports have performed terribly (largely because the file systems
    and process creation are so *different*).  If you are going the
    other way, I hope you don't use RMS very much (file structure
    compatibility checks? indexed files?  It's all a sequence of bytes,
    to U**x.).
    
    Putting all of that aside, (after all, this is a conference on
    *languages*, not on operating systems ;-), I would argue that, for
    most general purpose applications, neither BLISS nor C is the most 
    appropriate language for the job.  Both of these languages have
    the merit of being the "natural" language for some family of operating
    systems (that is, much of the "operating system", in the general
    sense of the term, is implemented using that language, and it may
    "interface better" than other languages typically can).
    
    Unfortunately, neither of these languages provide much support for
    an engineer attempting to create reasonably "portable" software.
    When I say that, I do not mean that, compared to assembly language,
    the code is not *very* portable;  rather, I mean that developers
    must constantly concern themselves with such low-level information
    as whether you pass a string using the address of a descriptor or
    by passing the address of the first byte in a zero terminated
    array of bytes (by the way, how do you interpret this latter one
    if you are working on a machine which is not byte-addressable? 
    one character per word?).  (Yes, both of these are partly operating
    system/calling standard dependent and partly language-dependent.)
    
    There is also something of a software quality issue, as well.  There
    has been some concern expressed the TLE::ADA conference about the
    "C"-ish nature of DECwindows interfaces (even the VMS, as opposed
    to the MIT [read U**x], interface).  [See 1031.5_or_so..1031.last.]
    To summarize, the problem is that the implementation language can
    often strongly influence the interface definition, or act as a set
    of unwritten/undocumented assumptions about what the cooperating
    modules must do.  For example, from a "C" point of view, it seems
    perfectly reasonable for a caller to pass the address of the first
    byte of a zero-terminated array of characters, while in VAX-land we use
    descriptors.

    Unless the language supports data abstraction (note, not just *allows*
    but *supports*) as well as procedural abstraction, it is difficult to
    design software which copes gracefully with such portability issues.
    However, if I program only in terms of abstract manipulations to some
    abstract datatype (say, strings), then the implementation of that
    datatype can be hidden from me and changed for different run-time
    environments, just as the two compilers may generate different calling
    sequences to satisfy the disparate standards of the two environments.

    Please, if you do go through the time and expense to convert software,
    convert it to a language which supports hiding of such details.
    Implement a compiler for all environments, if you must.  Use Ada
    (ignore tasking if you like, although it may become much more attractive
    in the future), Modula-2, C++, or something else which better supports
    data abstraction than FORTRAN, C, BLISS, or vanilla Pascal.

    Re .1:
    
> This company has such a tremendous investment in software written in BLISS at
> this point that I think it is likely that there will be a BLISS compiler
> for any new hardware platforms that DEC releases.

    This may indeed happen, but I'd question the move... If I have 10,000+
    lines of BLISS which I wrote for VAX/VMS, it's going to be painful to
    port them to VAX/ULTRIX because of VMS dependencies in my code, and
    it's going to be almost impossible to port it to a non-VAX
    architecture!

    Denis.

    We have to have some strategy for migrating to non-VAX platforms
    that doesn't shoot the billions of dollars invested in VAX/VMS
    applications over the last fifteen years.  We just can't afford
    to take a blank sheet of paper to the LSE, SCA, Notes, VTX, what
    have you groups and say here, rewrite this in C and tell us when
    you're done.

    re: .5
    
    You may find it interesting that a couple of years ago, people in TOPS
    land (10/20) wanted Datatrieve-32; took the BLISS sources, and made it
    work on a completely different hardware and software platform;
    TOPS-10/20 on PDP-10/20's. Those machines don't even have bytes, and
    you can't even pack characters (7 or 8 bit) into 36 bits without a bit
    left over. 
    
    It didn't take all that much work either. A lot of it depends how
    well organized and packaged your BLISS programs are.

    Was Datatrieve-32 written to be portable? There is a set of
    BLISS constructs (e.g. CH$ALLOCATION) to be used to make
    things more easily portable.
    			-John Bishop

The Datatrieve-20 port was probably the most carefully planned project I
witnessed in PDP-10 land.  I'll see if I can get someone to comment on it.
				/AHM

    	I was the project leader (and entire team for most of the
    development) of the port of Datatrieve-32 to TOPS-20. That experience
    and porting DECnet-Ultrix components to DECnet-DOS (see the Digital
    Technical Journal article on DECnet-DOS for more information) have
    fully convinced me that the choice of language is almost a moot
    point in determining the cost of porting. The degree of data
    abstraction and the separation of data manipulation algorithms from
    system interface algorithms fully determines the porting cost.
    
    	The Datatrieve-32 Bliss sources were written fully utilizing
    the facilities to provide portability. ALl character manipulation
    was performed with CH$, not addressing bytes in arrays. All data
    structures were defined using macros. All I had to do to make the
    code work on 36 bit machines was to re-write the data structure
    definition macros. In addition, the modules carefully separated
    system interface specific algorithms from data manipulation
    intensive algorithms. I actually recompiled, without even reading,
    the components of Datatrieve-32 which compiled and executed the
    parse trees. I had to essentially rewrite the parser and the execution
    action routines. There are many modules that I have never read in
    Datatrieve-20!
    
    	The DECnet-DOS experience was identical. I recompiled DECnet-Ultrix
    FAL on MS-DOS and had it running in a single day. This was because
    the data abstractions and C runtime system are almost identical.
    However, the work to make FAL support multiple connections concurrently
    took 6-9 months to design, code, and fully debug. Ultrix ran multiple
    forks to do this, and MS-DOS is single tasking.
    
    	So, don't worry about the language at all. Worry about the
    definition of data structures and the abstractions for process control
    and assumed system services. C won't help you when you go hunting
    for the lock manager, or global sections, or FIND_IMAGE_SYMBOL on
    OSF/UNIX.
    
    Peter Mierswa

    Re .10:
    
    We should note that this is written in the context of a 
    Bliss => Bliss porting effort for a product which performs significant
    implementation-independent processing and which was written using
    language facilities to support portability between the two
    environments.  It is not clear that we can directly apply this
    experience to products which have a greater degree of interaction
    with operating system facilities (such as the "C" => "C" port of
    DECnet-Ultrix which included 9months for dealing with concurrency
    issues).  VTX may be an example of such a product.
    
>    	So, don't worry about the language at all. Worry about the
>    definition of data structures and the abstractions for process control
>    and assumed system services. C won't help you when you go hunting
>    for the lock manager, or global sections, or FIND_IMAGE_SYMBOL on
>    OSF/UNIX.

    We can certainly say that a Bliss-X to Bliss-Y conversion (assuming
    "nice" coding) or a X-C to Y-C conversion (with similar assumptions)
    can go well, so long as the degree of processor and operating system
    dependency is minimal (ie, the software was "built-pretty-portable"
    in the first place).
    
    .10 highlights the importance of the abstractions designed into 
    the software in determining the portability of a given application.  
    Also, it is certainly possible to code for future port-ability and 
    minimize the effect on an overall software design to achieve 
    acceptable performance (plan on record-oriented I/O and relatively 
    expensive process creation, and both a VAX/VMS and Ultrix 
    implementation could perform well).
    
    However, even though it is *possible* to build "portable software"
    in most languages, it is much *easier* to do it when the
    implementation language directly supports both data abstraction and
    procedural abstraction.
    
    If you have a product which *must* be massively rewritten for a new
    environment, you should worry about the language just a little bit;  it
    could encourage a more portable implementation that will allow you to
    save time and money in the long term. 

    Lloyd

    re: .10
    
    From my second hand experience (from Peter Vatne), I believe there were
    some amount of problems with missing CH$PTRs in the code. In BLISS-32
    ch$ptr(x) = x; and ch$plus(.x,1) = .x + 1; not true on TOPS. And, a few
    problems with byte arrays as characters. 
    
    Maybe that wasn't overall significant, but it did cause some level
    of initial problems.

I like the following strategy.

	Create another Bliss back end.  But instead of producing
	object code, this Bliss back end produces C source code.

This may cause compilations to take 2X-3X as long, and program debugging 
will be awkward.  However, we need only do these 'cross-compilations'
on software that's already been tested/debugged on our strategic platforms.

The performance of the generated code may suffer, but some research at DECSRC
(compiling Modula-2+ into C) indicates it may not be bad at all -- their results
indicate a performance difference that's usually less than 2 percent!

The advantages?  We get our Bliss products ported quickly to other platforms.
And we spread out the costs of going to C (learning, etc) over a longer time.

This isn't a universal panacea, though.  If the Bliss code is not written
to be portable, it's unlikely that the generated C code will be much better.
Of course, you potentially have that problem whenever you port Bliss (or C)
code to a different architecture; that's an independent issue.

					- Gilbert

Re .13:

I wonder if there are any significant Bliss control or data features not
expressible in C?  Linkages probably don't matter.  Runtime expr<p,s,e> wouldn't
be efficient, but would be doable.  Do any nastier constructs come to mind?
				/AHM/THX

    Shifts would be a little ugly if by variable amount or to the right,
    since C has separate operators for left and right shifts, and right
    shifts of signed values are implementation defined as to fill.

At the end of the VAX Fortran/Ultrix project, we estimated that it would take
about 1 month to port BLISS-32 to Ultrix.  Most of that time would be taken up
in doing library support.  BLISS is the easiest language to port because it
has no RTL of its own.  If you don't mind a cross development environment, we
have it now - the entirety of VAX Fortran/Ultrix is written in BLISS and
developed on VMS - the objects are simply copied to Ultrix and linked there.

Thus, the issues have nothing to do with BLISS and C as languages, they have to
do with system service calls.  Converting to C doesn't do anything to solve that
problem.  Besides, many of the "easy" VMS services have already been ported to
Ultrix as part of the same project, like RMS calls for OPEN and sequential
reading and writing.

Please don't confuse the issues of porting existing products to Unix with the
issues of converting to C as an implementation language - they are entirely
different.
	-Kevin

One month?  I was going to steal the sources and do it over a weekend.

--PSW