Conference turris::languages

There are biases against using high level languages almost everywhere.
I contunue to be absolutely amazed at the number of people in the "real world"
who truly believe that there is no suitable high lavel language for system
programming. These people will spend months writing code to scan command lines
or do other non critical tasks in 8086 assembler, all the time complaining
that "high level languages generate code that is too large and too slow",
and then burn code that searches huge tables with linear searches into the
first half of a huge ROM.

I think there is a bit of a bias against BLISS. It is a little harder to
get started in BLISS than it is in C (C is, from where I set, the biggest
comptition it has right now). I do feel, however, that the "how long it
takes to learn ..." arguments are empty. Most of them have the feel of
"it takes longer to learn to use BLISS well then it takes to learn 50%
of C adequitely". With the assistance of a macro package to make it a little
easier for the novice to declare simple records, and a standard I/O library
of reasonable power (the C one might do!), I really don't believe that
BLISS is that much harder to use than C. The "." is no harder to learn than
all of the "*cp++" idioms.

dgc

I wonder if this is a religious bias deriving from the dictum, "When thou
develop a development system thou shalt use thine own product as thy 
development system."

I seem to remember in the early days of RSX there was a big philosophical
debate over this.  Specifically at Bell Labs they were using Unix to
develop real-time switching systems that didn't run on Unix, but on some
other OS.  DEC was plugging RSX as a real-time system that you could do
development on, and it was important therefore to actually use it for
development, and the RSX development group was the obvious candidate.

  Well, us DEC software engineers are pretty versatile and can program in
  whatever language is convenient.  Assembly is one of the choices.  I think
  that for most programming tasks it is a lousy choice, for the following
  reasons:

	o Assembly language programs are not generally considered
	  transportable.

	o Higher level languages use English language keywords that are more
	  easily understood than the corresponding sequence of machine
	  instructions and labels.

	o Higher level language users indent their code to make loop bodies
	  and "arms" of conditional constructs stand out.  Assembler users
	  generally don't.

	o Assembly programmers have to keep track of what's in every register
	  at every point in the program.  This isn't impossible, it's just
	  another error-prone task that compilers handle nicely for you.

	o Compilers are generally more methodical when it comes to deciding
	  which variables and temporaries are used  sufficiently often that
	  they deserve to be in registers (BLISS compilers in particular).

	o Compilers are better at deciding whether to use long or short
	  forms of instructions.  This involves a lot of bookkeeping, and
	  can change whenever the program is modified.  In a small address
	  space such as the PDP-11, the penalty you pay for using short
	  conditional branches around long jumps unnecessarily is severe.

  -- Bill B.

One of the biggest problems I have had personally is backing off from the
nits of MACRO programming.  I find that when I write in MACRO I spend too
much time rearranging code and registers and generally rewriting the same
code segment over and over to minimize the code size and to avoid the use
of stack locals.  I know that its stupid but I can't help myself.

When I started writing in BLISS I spent a lot of time worrying about the
code sequences generated and the trying to make the BLISS code be as tight
as the MACRO code.  In the process I learned a lot about BLISS and its
code generation.  I am slowly becoming far less concerned about how the
code compares to the "optimal" machine code and more concerned with just
generating good code.  I am learning that by first starting off with an
appropriate algorithm, generating the code, and making it work, that if
I want to fine tune it I can do so at this point.  Then as refinements are
made, the BLISS remains readable, the machine code pretty decent, and the
registers and labels and branches change to almost best use the machine.
If I were doing it in MACRO, every step of the way I would be reallocating
registers and labels and rewriting to keep the machine code fine tuned.

I guess this is a result of coming to DEC at the time when Cutler stamped
all memos with "SIZE IS THE GOAL".  This was quite reasonable when you're
trying to fit in a 16KW system that cost more than a 730 does today.

There are times when assembly language is appropriate.  For example,
one should sweat blood doing careful coding of context switching
in an operating system, right down to checking the timing of each
instruction and knowing the hardware well enough to overlap
memory cycles and all that stuff.  On the other hand, when was the
last time any of us coded a context switching routine?

Design is much more important to performance than language.  VAX VTX
has very good performance, and there isn't a single line of MACRO-32
code anywhere (it's all in BLISS).  On the other hand, a lot of
thought went into the design phase to maximize performance.

In the days when we only had 16-bits (with no magic PLAS directives)
and the standard CPU was the 11/34, it made sense to sweat every
instruction.  By next year, when the smallest VAX will be the
MicroVAX II (about the same power as a 750+) with 32 bits, the
emphasis should be on maintainability.  That implies a higher
level language.

john

A lot of it is just plain human nature too.   Most of us have been using
BLISS for a while, and I don't really mind any block structured language.
However a notice for a BLISS course went around the other day, and you'll
never find the people who used MACRO since day one sign up.    

Maintainability has to be the number one concern in software, right up
there with flexibility (the ability to be bastardized into something you
never intended to be..) and trying to pick an algorithm out of MACRO code
is just plain painful unless A) you wrote it.. or B) the code is documented
to end all (which never happens).

Strange.  You usually see people who know high level languages learning 
ones closer to the hardware, but not the other way around..

Rick

Re .5 - since when was context switching such a BIG deal????  The cache
flushes and CMKR and timer interrupt serving and accounting and ... is such 
a big overhead to start with that I bet you really couldn't tell if the
actually context switching code was 3 times longer...

/Bevin

My reaction to the statement about context switching was similar.  For RSX
it is so complicated, that a high level language might produce better code
because you would be able to better understand whats going on.  And for
RSX-11M-PLUS, the SIZE IS THE GOAL axiom has been changed to USE MEMORY WISELY
and so the contex switching code can grow considerably if it provides better
performance.  This was done for the last release by unfolding loops and
special casing the normal cases.  However, the extent of the changes is very
limited because of problems like branches breaking and logic errors creeping
in for exception cases.

Interrupt service routines for devices like DZ-11s may be a different story,
but I'm going to code it first in BLISS and see if its a problem.  Clock
interrupt service routines are no problem; 30 extra instructions at 60 HZ
means that you lose 1800 instructions per second or about .2% of the cpu.
Better to spend the time on the terminal output case where about the number
of interrupts exceeds 5,000 per second.

	Well, I don't know where I fit into this.  I like to program in assembly
language, but of course that takes time when moving from system to system.  Be-
fore I came here, I was doing consultant work.  I learned C so I could transport
tools and algorithms around.  (That's one good thing about C:  There are so many
tools written in it and so many of the sources are public-domain.)
	My favorite higher-level languages are Lisp (for intellectual reasons)
and C (for practical reasons).  However, I do like assembly language because (1)
better performance, and (2) more control over what happens.
	Like I said, though; assembly language takes time to get adjusted to.  I
still haven't gotten very competent in VAX MACRO.
	I wonder if it would be possible to make assembly languages more reada-
ble with proper indenting?  That might be interesting...
		<_Jym_>

Some Burroughs assemblers are truly block-structured languages.

Supposedly the PDP-10 assembler FAIL has nested scopes, but I never heard
that it had support for higher level abstractions.

The PDP-10 assembler MIDAS has a pseudo-op that takes an expression as
an argument, and results in the generated code for the expression.

There was a language called LIL (Little Implementation Language) on PDP-11
Unix systems which sort of looked like a Bliss that could only have a single
operator on the RHS of an assignment.  I never met anyone who used it, but
it seemed like a cute alternative to traditional assemblers.~r

Oh, and the Tops-20 group uses a bunch of macros to structure their
brain waves when writing in Macro.  I have seen macros that provide
structured control flow, and macros such as LOAD and STORE which, when
provided with a structure field name, will generate a fullword MOVE,
a Hxyz 18 bit data move instruction, or a nice slow generic byte instruction.
				/AHM