Conference turris::languages

Bliss is unique among langauges in its ability to interface with
routines that use arbitrary calling sequences.  Also, the differences
between implementations with respect to target machine architectures
are very well defined.  But realize ahead of time that you must be
alert at all times to portability considerations.  Inattention to such
considerations during the initial implementation will create work later
on.  If you want the eventual port of the code to be low-cost, you
will definitely have to make an investment in vigilance to meet that goal.

And, as Keven Harris has pointed out, it is still the default implementation
language for new projects.  Until BJ writes another memo endorsing some
other language, people are supposed to show cause why they *aren't*
using Bliss, not why they *are*.  Those of you snickering in the
background should excuse my naive notions of reality, I am only repeating
one of the policies we are supposed to adhere to.

You could also damn the torpedoes and use assembler, or use C or some
other language.  If the cost of inserting jacket routines between the
existing routines and what you write is small enough, it is possible.
If anyone has any comments on using C, I would be interesting in hearing
them.  Many of the same issues will arise as Tops-20 moves from assembler
to C, and other's opinions and experiances would be of great utility to us.

Also, if any other languages are in the running, what are they?
				/AHM/THX

A few months ago, someone was going to benchmark Bliss-16 and
Decus C.  Does anyone know how the benchmark turned out.

We have, by the way, an extensive benchmark (about 1/2 of DECtalk)
that we've run on various architectures (PRO-350, PRO-380, Vax-11C,
Motorola 68000, and Rainbow (8086)).  We'll post some information
when it's cleaned up a bit.

Martin.

Since this note looks like it may just turn into yet another BLISS-vs-C
note, I might as well start it off. It may help you make your decision.

C is a good choice. It is a small language, easly compiled into code of
acceptable quality on a PDP-11. It can describe all of the data type on
a byte addressed machine well (with the exception of unsigned bytes in
some implementations; this is most-of-the-time ok, because if you say
"c&0xFF" you get "movb c,r0; bic #^C<377>,r0", which is as good as half
of the MACRO programmers).

The subroutine linkage is fixed. You have no choice but to use it. The
call-return overhead is the JSR plus saving registers. All functions are
recursive. 

Data structuring is satisfactory for about 90% of cases. You can build
records and unions using the basic types. The only things that are clumsy
are type safe variant records (After much fighting I have found a way using
unions, lots of secret names, and #defines (macros) to hide all of the dots
that is very readable, and hides most of the details).

There is an extensive library of routines to hack strings, allocate memory
and do I/O that is very compatable across implementations of C. This may
be the languages strongest advantages.

BLISS is also a good choice, as long as the universe of machines upon
which you want to run is the same as the universe of machines built by
Digital. The compiler is large and not too fast, and unless something
has changed since I looked last, the compiler does not run on the PDP-11.
There is no way to deal with floating point numbers.

You have more flexability w.r.t. routine linkage than you may ever need.
If you have to interface with a lot of code that uses strange calling
conventions, you can (usually) call them from BLISS without envelope
routines.

The data structuring facilities are more general than those of C, but
require you to do more work right at the start. You have to take more care
to define portable data structures than you do in C. They are better for
hiding the details of implementation than those of C.

On the other hand, BLISS is untyped, so you have to be careful to be looking
at a block of data (especially a variant record) through the right coloured
glasses; if you get it wrong you don't get a lot of help.

The explicit dereference operator (".") is a shock to most at the beginning.
I am not a fan of it. In its defence, the treatment of names is uniform, and
I have written thousands of lines of LISP, where the same thing is true, and
I didn't object one bit (buy "same thing" I mean "explict dereference", as
in SET vs SETQ and SELECT vs SELECTQ).

I have also found that some BLISS programs pull thousands of lines of
macros from require files, and then are written in languages that have all
sorts of syntax extensions, blank lines, et al. I found that these programs
are harder to read than those written in the base language with minimal
macros (this is just an opinion; as a specific example, I find the CODE 
part of the microbliss compiler much easier to read than the TEMPALLOC
phase).

It would be nice to have a standard library. On the other hand, the
C library can probably be called from BLISS with a bit of an envelope
around it.

I would write in either before I would write in MACRO. I would avoid
PASCAL, although this may just be personal bias. BLISS and C are probably
both acceptable choices. Both languages have their good points and their
bad points. The final decision has to be based on the experience(s) of the
people in your team, the development environment (i.e. is in an 11/23),
and just plain personal preference. Try to avoid getting pulled into the
holy wars that surround this choice; you will not win.

dgc

As I recall there is a BLISS compiler that runs on PDP-11's, I think it may
run on RSX and RSTS.   They used to call it MICRO-BLISS, but I dont know what
now.

Rick

DONT TURN INTO another BLISS v. C note!  Keep that discussion THERE.

/Bevin

BLISS is the right choice. You give all the reasons yourself, and .1
explicates them sufficiently. Reply .3 states sufficiently states the case
for C, which would be my second choice.

But here's an unusual result: it might be DECnet, not the language features,
that dictates the choice. I would pick BLISS-16 in a VAX to PDP-11
cross-development environment if your PDP-11 development system supports
DECnet, otherwise I would pick a good compiler that runs on the PDP-11.

Basically you want all the compute power you can muster, in order to
minimize the test, debug, edit, compile, link, load, test cycle. But if
your target system doesn't support DECnet the time you've saved by
editing, compiling and linking on the VAX may well be eaten up in walking to
the compiler system, making a tape, walking to the test system, and loading
the tape. In that case you might be better off working in C on your
PDP-11.

Before I picked C for PDP-11 development I would want to see a benchmark
comparison of C versus micro-BLISS.

[Sorry about the blank reply; I typed "reply" and then, for some silly
reason, ^Z].

Re 6.
I would like to put my vote in for doing development on the largest machine
available. All too often I have seen projects grind on because they were done
on two small a machine. The very worst cases are usually the folks who try
to use those wimpy development systems that come from the microprocessor
chip manufacturers.

I ran some "mini-benchmarks" myself between C (the DECUS implemntation)
and BLISS-16. This was primarily a compiler writer's interest on how
BLISS-16 used machine registers. In general the code was very similar for
similar expressions. Both were using a "push the arguments, call the routine,
and pop them off with an ADD" calling sequence. C always saved a fixed # of
registers, by calling a save routine. BLISS won here, because it would often
save less stuff. It also did not tie up R5 with (essentially) a copy of
the SP. BLISS also recognized common sub expressions, which the C compiler
did not; on the other hand, it has been my observation that C programs tend
to do common subexpressioning manually, with temporary variables, so you
don't win by as much. Sometimes BLISS-16 would generate extra register
shuffles when it had to generate a MUL or DIV and the temporary got bound
to an even register.

Does MICRO-BLISS understand EIS? The last time I looked it called OTS
routines for multiply, divide and long shifts.

dgc

First, I would avoid Micro-BLISS for several reasons.  Mostly, it
is not a supported DEC product.  It may work now, but if something
strange happens you're on your own.  Also, BLISS-16 puts out much
better code than uBLISS.  Some time ago we looked at uBLISS for
a language project and found that the code wasn't as good, a lot
of language features were missing, and it was possible for a large
program to blow uBLISS's memory.  So BLISS-16 is definitely prefered
between the two.

If you are on a 780 doing development for a 11/23, obviously
a program will compile much faster on the 780 than on the 11/23,
even when you take into account the overhead of moving the OBJ
file to the 11/23 when done.  Also, editing on a 780 gives you
a wide choice of editors and code management systems.  While these
are not specifically tied to a particular language, it does point
up that doing cross-compiles is not such a bad thing.

john

Thanks for the comments; I welcome others.  In response to some of the
questions:

Other lanuguages in the running?

MACRO - I certainly don't consider it to be transportable unless something
like supermac was used.  Nor very high level.  This is a very poor alternative
in my mind.

C - I'm concerned by the lack of a supported compiler, the lack of any C
experience in the "group", and the quality of the code in terms of the lack
of flexibility in things like linkage and volatile declarations and tools
available.  My biggest concern is certainly the lack of C knowledge on my
part; this lack of knowledge may cause me to be overly concerned about code
quality.  The support issue probably isn't too important as long as we are
willing to depend on the good will of Martin, et al.

One of the reasons for asking was to make sure that there weren't alternatives
I hadn't considered.

Target machines?

Currently only PDP-11s and VAXen are target machines.  A 68000 is explicitly
not a target.  Ditto other commodity cpus.  One of the requirements is the
support of Software Services development of specialized LAT servers.  This
will mean that the code will be available to customers (even if licenced, etc)
and I see the lack of code generation on non-DEC equipment as an advantage.
(Actually BLISS compilers do exist for other machines, but they aren't DEC
dialect.)  The cost of all the servers currently planned is dominated by
the interfaces and packaging, not by the cpu.

Development environment?

The target machines do not present a good development environment, but they
can be easily downline loaded (in fact this is a requirement for a LATserver).
I have developed RSX software using a VMS host for a number of years and
would find it very difficult to use anything less than a 780 class machine.
I also expect to use some tools (and probably develop some) that require
the address space of a VAX.  I like the idea of CMS and MMS and currently
am using CMS for source control.

The real question?

I'm not sure how to express it, but most of the people I work with are anti-
high level language.  I'm not sure if this is because of my RSX background,
my PDP-11 background, or operating system development background.  BLISS has
a very negative reputation which I consider unwarrented.  The original BLISS
implementations were in my opinion harder to understand, but I feel the
current BLISS dialect to be fairly easy to understand.  BLISS is different
from languages like FORTRAN and C because it does present a more abstract
model of control and structures, thus the lack of GOTO and the "dot".
However, one of the goals of using a high level langauge is to express the
abstract algorithm instead of the machine code realization, the idea of
using abstract language contructs shouldn't be that difficult to accept.

So am I just paraniod, associating with the wrong group of people, fairly
representing the situation, or making the wrong choice of language.  So far
the comments indicate that its not the latter.  See a new note for a
restatement of the anti-high level language question.

With respect to a comment or two about how slow the Bliss compiler runs:

Yes, it's slow.  However, here in the Bliss project, we are working on
giving you folks some relief.  We expect a significant decrease in compile
time in our next release.  

mark

By the way, BLISS does too handle floating point, all four datatypes even!
Said support is a bit clunky, though, generally requiring by-reference
for all operands.  I have a "floating-point range extension" handler
written entirely in BLISS.
				Steve