Conference turris::languages

    Two that I can think of:
    1. Writing a transfer vector for a sharable image.
    2. Writing a device driver (more precisely, the part that accesses
       the device registers, where you must be careful of the instructions
       used)
    	-Rick

    Only 5 occasions?  This is silly.  Assembly language is often the
    only thing that makes sense - at least given the state of things
    on VMS today.  I wouldn't write high-performance math routines in
    anything else.  Also, code that juggles call frames (such as the
    code in the exception dispatching facility, Ada multitasking (on
    VMS), etc.
    
    But it is true that MACRO is used much more often than is necessary
    in VMS.  Modula2 is not a standard DEC development language, so
    why learn it over others?  If you want a good high-level applications
    implementation language, pick Pascal or Ada.  And it's foolish not
    to learn BLISS if you work for DEC.
					Steve

Re .1:

I thought that either Macro or Bliss could be used for device drivers
on VMS.  (Not that I've written any in either language).

Re .2:

I believe that DEBUG wades through stack frames using Bliss code, including
the use of symbols from STARLET instead of magic offsets.  On the other
hand, the condition handling facility might be one of those places where
the last bit of speed counts.

Also, I read about 4 defined levels of VAX diagnostic software someplace
recently, and two of them can only be done in Macro.
				/AHM/THX

    Since I work at the DDC I don't really have to do any programing
    whatsoever.  I just wanted to learn a language different from Basic.
    My home micro can run just about any 68000 based language.  Pascal,
    Fourth, Modula2, Fortran, Macro and Basic are the offerings presently.
    It seemed that since Pascal was so popular that Modula2 was the
    appropiate choice. But then again I am a complete novice, (so what
    do I know?) B^)
    
      Mikie?
    

    	My Bliss manual does not show a way of generating a SVPCTX
    instruction, and as far as I can remember device driver FDT routines
    normally terminate with a JMP to an address in VMS, so probably
    both of those things should be done in Macro.
    
    	Self modifying code is always fun, and I would hate to try that
    in anything other than Macro....    :-)

    VMS drivers can ONLY be written in MACRO, not BLISS.  (But this
    is a VMS property - on VAXELN, one can write drivers in Ada!)
    
    Of the languages you list, I'd pick Pascal as being the one most
    unlike BASIC that is similar to "real" languages of today.  I like
    FORTRAN too.
    					Steve

    Re .6:  But, drivers can call FDT routines written in BLISS.  So
    while much of the driver must be written in MACRO, lots of the hard
    work can be done in BLISS.
    
    stephen
    (the VS100 driver was written that way)

    I *really* don't want to start any wars, but I work for DEC and I write
    all of my code in C and Modula-2, and I don't have much motivation to
    learn MACRO *or* Bliss. (Actually I once knew Macro-11, and I have a
    nodding acquaintance with Bliss.) 
    
    I work in UEG.
    
    Enough on that subject.
    
    If you want to learn a good, fairly "modern" language, that was
    designed to support modular design, information hiding, and other
    such "good" things, then Modula-2 is an obvious choice. Arguing
    about the merits of one language over another usually devolve into
    shouting matches, or religious arguments, or (rarely, when all
    participants are reasonable) an agreement to disagree on matters
    of taste.
    
    Pascal is a reasonable language, but it's lack of an integrated
    "separate compilation" feature makes it difficult to call a "modular"
    language. Granted, many if not most versions of pascal available
    today have some kind of modularity, but I claim (opinion here!)
    that they are not as well integrated as in Modula-2. Since both
    languages were designed by the same person, and Modula-2 was designed
    later, and for systems software, I'd learn it.
    
    [Actually, I'd rather write in Mesa, but that's another story...]
    
    Ada is a fine language, but it suffers from a scarcity of decent
    implementations. My impression is that it is a "large" language,
    unlike Pascal, or Modula-2. If you have Ada available to you, by
    all means learn it, and use it.
    
    After all that, I have to say, if I were out shopping for a language
    translator for my PC today, I'd buy Turbo Pascal. It's fast, it's
    mature, and it's available for a wide variety of machines.
    
    	Hope this helps,
    	-- Charles

    The draft extended Pascal standard has a separate compilation feature
    that look alot like Modula-2 (IMPORT, EXPORT, IMPLEMENTATION, etc...).
    
    I'd rate it more than Modula-2, but less than Ada.
    
    Other features in the new standard may make standard Pascal a usable
    language if it can overcome its reputation.
    
    			-John

< Note 117.9 by TLE::REAGAN "John R. Reagan" >
                            -< Pascal is improving >-

At that rate, sames like Pascal and Ada will almost converge, with the exception
of Ada having overloading and tasking? (what else did I forget ...)

And, of course, ACS. How can you live without a compilation system manager? :-)

RE: 117.7

If the FDT routine does anything non-trivial, it cannot be written in BLISS.
Many of the system interfaces for drivers have ugly calling conventions
such as:  system JUMPs to your code, you RSB back, or vice versa.  BLISS does
not support such calling conventions.

Even if it is possible for particular FDT routines to be written in BLISS,
it is not a good idea because it is totally unsupported.  The only supported
driver interface macros are in MACRO.  If you write a driver in BLISS, you're
on your own.

--PSW

    Thanx for all the comments folks.  I'll probably wind up with Modula2
    or Pascal.
    
      Mikie?

    
    	Just out of interest, it is possible to write a driver in BLISS
    (well, only using about a page of MACRO). Indeed, I know of drivers
    for three forthcoming devices, which are written in BLISS.
    
    Trev

    Re: .13
    
    If you need MACRO at all, then clearly the whole thing isn't in
    BLISS.  That a lot of the driver can be in BLISS is good, though.
    					Steve

    All the drivers in Ultrix/Unix are written in C.  The drivers for
    the Cambridge something-i-forget-the-name-of-it'll-come-to-me-in-a-minute
    are written in Algol 68 aprt from stubs to get some registers into
    veriables.
    
    								jch

|    	Just out of interest, it is possible to write a driver in BLISS
|    (well, only using about a page of MACRO).     
    
A few years ago (VMS V2.n, V3.0 days), a couple of demented software people
and I hacked together a LPDRIVER which was "mostly" in BLISS. We used MACRO
to define the data structures (DPT_STORE, DDBTAB, FUNCTAB) to avoid a major
recoding effort, and I think that was all.  I've got the source somehere on
the 31 magtapes in my office and at home; if there's any interest, I'll see
if I can dig it out.


			Nigel

    To my mind, the four most important reasons why BLISS isn't very
    suitable for writing drivers are:
    
	You can't generate the driver prologue.
    
    	You can't have anything extra on the stack when you call a resource
    	allocating procedure (e.g., REQMPR).  The stack contains only the
    	second return PC.
    
    	You can't control the instructions that are used to access the
    	I/O page.
    
    	The interrupt service routine has to do odd stack manipulations at
    	the beginning and end with REI.
    
    In a driver for a complex device, there may be algorithms of
    significant complexity that need to be executed without interacting
    with the system-provided I/O framework, so it may make some sense
    to consider BLISS for these pieces, but I wouldn't go to the trouble
    unless they were big pieces.