Assembly VS HOL: Having it both
j...@wdl1.uucp
The idea of machine-dependent medium-level languages was worked to death
in the late 60s and early 70s. Look up ``PL/360'' in a good computer science
library. In retrospect medium-level languages were a bad idea; nothing more
machine-dependent than Bliss ever went anywhere.
John Nagle
D Gary Grady
I've seen PL/360 and I believe it still has some users at Stanford; at
least you could still get documentation from them as recently as about
three years ago. IBM today uses a machine-dependent "medium-level" (one
might argue about that in this case) language called PL/S for its
operating systems nowadays, though I don't believe this is quite as
powerful as what I have in mind. And I repeat that Burroughs large
systems have no assembler but use instead a dialect of Algol. So the
idea is not quite as dead as all that.
If problems were found using these languages, what were they? Was it
really that, say, PL/360 was unusable, or was it inertia or
unavailability that caused the problem? In short, if they're better
than assemblers, why not use them, and if they're not as good, what is
it that keeps them from being as good?
--
D Gary Grady
Duke U Comp Center, Durham, NC 27706
(919) 684-3695
USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
Ned Horvath
I was using it (early 70's) I considered it an excellent alternative
to assembler.
It was a bit curious in the sense that you had to KNOW the architecture of
the 360 (nonsense like multiplies requiring even registers and leaving the
result in an even/odd pair, funny stuff about R0, etc.) in order to use it --
the sort of thing only assembler programmers ordinarily know. Given that
prerequisite, however, it was MUCH more convenient to define data and code
than assembler was. Perhaps it was too nuts and bolts for HOL programmers
and too effete-looking (ye gods, block structure!) for died-in-the-wool
assembler types...
But I suspect that what killed the likes of PL360 was advancing compiler
technology. A lot of us learned C using the Ritchie compiler on the 11,
and it didn't take too many 'cc -S' runs to convince you the thing wrote
HOT code; folks who ought to know tell me that Bliss is alike in this:
you can still touch the hardware when you need to, but the rest
of the time you can pretty well ignore the underlying architecture.
The best PL360 story I know is indicative of a greater lesson, germain to
this discussion: Al Demers was unhappy with the 'roff' version then running
at Princeton, and the Comp Center folks weren't giving him any satisfaction.
So, he coded a roff end-to-end in a week or so, in spitbol -- a great
prototyping tool for such a task, albeit too slow for large documents.
Having made his design errors in a cheap prototype, he proceeded to recode
a (now much better understood task) in PL360 -- again, in a week or so.
The result was a much-enhanced roff facility that ran like a bat.
=Ned=
John Mashey
> But I suspect that what killed the likes of PL360 was advancing compiler
> technology. A lot of us learned C using the Ritchie compiler on the 11,
> and it didn't take too many 'cc -S' runs to convince you the thing wrote
A supporting example is LIL (Bill Plauger's Little Implementation Language
at BTL in the early 70's), which has about the same semantic level as PL/360,
and never quite caught on. Bill once gave a talk in which he said that
LIL was a language whose time had come... and gone, because every time
he thought he had a niche where it beat C enough, Dennis improved the compiler.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD: 415-960-1200
USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
Darrel VanBuer
two deficiencies, one minor, one major.
The minor one was that the opcode coverage implied by "conventional"
programming was fairly narrow, mostly branching, integer and address
arithmetic. Other opcodes were written as procedure calls, and you were
able to define new opcodes easily.
The more significant one was the almost complete lack of system interface
support. In assembler you have a large library of macros for system calls
(SVCs) and standard idioms. PL360 came without such a library, and its
register use conventions tended to conflict with those of SVCs, so it was a
little tricky to call the operating system. I had my own library for these
things, but most of the systems calls became subroutine calls to short
routines which dealt with the funny register mismatches.
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VAN...@USC-ECL.ARPA
ase...@cascade.arpa
message appeared:
> Stanford may still have PL/360. They still have ORVIL, WYLBUR,
>Algol-W, and a number of other antiques running on the IBM iron.
>In fact, the Stanford CS department's latest new machine is a DECsystem 2060
>that DARPA had left over from some project elsewhere and offered to Stanford.
>Stanford still has the old Incompatible Time-Sharing System running on SAIL,
>after all these years. The fact that something is still in use at Stanford
>reflects only that Stanford got into the business early.
>
> John Nagle
"Stanford" is a reasonably large university. It's computing
environment is far from monolithic. ORVIL, WYLBUR, and the IBM iron
are part of the university computing service and have nothing to do
with the Computer Science Department. There are a LOT of places out
there that still use IBM machines as their main computing resource; the
above remarks make about as much sense as stating that some physics
department somewhere is antiquated because they use a PDP-8 to analyze
data from some machine. Also, SAIL doesn't run, and has NEVER run to
my knowledge, the Incompatible Time-Sharing System (ITS); I don't think
that ever got out of MIT (thank God!). The CS & EE departments have at
least 10 Vaxen running 4.2 Unix. Stanford's computing resources
may not be all that we could wish, but they're far from being in the
dark ages as John suggested.
-paul asente
decwrl!Glacier!Cascade!asente ase...@Cascade.ARPA
D Gary Grady
> Burroughs Algol was a high-level language, at least as high-level as C
> or Pascal. So is PL/S. But PL/360 is totally nonportable and makes the
> register structure of the target machine, for example, very visible.
> It's a different kind of language than most programmers are used to.
> One of the key properties of a medium-level language is that the programmer
> is not insulated from the machine architecture at all.
Burroughs Algol is a fairly machine-specific Algol - I certainly don't
know of another computer it would run on. This is true in practice of
PL/S as well. And I certainly wouldn't argue with the points about the
concept of a medium-level language being unfamiliar and their not
insulating the programmer from the architecture. But I fail to see what
you're getting at. All these failings (if they are failings in the
context in question) apply to assemblers as well.
What I would like to see is a good alternative to assembler language,
one that would allow high-level constructs when they are useful and low
level machine control when that it useful. It is obvious that such a
language would have to be machine specific, though it is also
reasonable to suspect that some degree of portability in syntax could
be achieved (there have been portably assemblers written, believe it or
not). However, I think portability is quite irrelevant. If I want
low-level machine control I HAVE to give up portability, absent
considerations of what language I write in.
To restate in a sentence: I'd like a language that gives me the power
and convenience and readability of a high-level language but the
low-level control of an assembler. I see no reason for incompadibility
between those two needs.
Chuck Simmons
> and convenience and readability of a high-level language but the
> low-level control of an assembler. I see no reason for incompadibility
> between those two needs.
Why can't we write most of the program in our favorite high-level
language and then write critical portions of the program as subroutines
in the local assembler? This requires that the assembler have a way of
specifying type information, etc to the linker, and it requires that the
subroutine interface of the high-level language be well documented. On
the other hand, to port the program to another machine would (hopefully)
require only rewriting the assembler routines; which we would expect to
be short and well-written. (This is how we write programs around here.)
On the other hand, it has been argued that C is a high-level language.
Meanwhile, C appears to provide the programmer with the low-level control
of an assembler.
Chuck Simmons
D Gary Grady
> language and then write critical portions of the program as subroutines
> in the local assembler? This requires that the assembler have a way of
>
First, there's the matter of subroutine calling overhead, which is
sometimes a problem. Second, I still wind up writing in assembler.
Maybe what I should be squawking about is a better syntax for assembler
language than the traditional one...
Mark Galassi
>What I would like to see is a good alternative to assembler language,
>one that would allow high-level constructs when they are useful and low
>level machine control when that it useful. It is obvious that such a
>language would have to be machine specific, though it is also
>reasonable to suspect that some degree of portability in syntax could
>be achieved (there have been portably assemblers written, believe it or
>not).
>Duke U Comp Center, Durham, NC 27706
>(919) 684-3695
>USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
That is what I have always thought C was: a language that allows you to
do all you want to the machine (almost) and yet has high level constructs.
Ozan Yigit
>language than the traditional one...
>--
>D Gary Grady
Have you heard of SMAL/80 ??? It was a "structured assembler" written
in Bell Labs for 8080/Z80 processors. It looked much like C, and it was
VERY readable..For example:
intel zilog smal/80
JPE addr JP PE,addr if even goto addr
XRA C XOR C A = A xor C
INR A INC A ++A
MOV B,A LD B,A B = A
It also contains a LOOP - REPEAT construct and IF cond
stmt construct.
Maybe it is time to revive this neat little language for the newer
set of architectures.
Ref: IEEE MICRO, Feb. 1982, Vol 2 #1. Pp. 63-71
Oz [whizzard of something or another, no doubt..]
Usenet: {decvax|ihnp4|allegra|linus}!utzoo!yetti!oz
Bitnet: oz@yuyetti
Jonathan Clark
Please God save us from any more high-level assemblers, like
SMAL, or PL/Z, or anything else (not macro assemblers,
though. They are very useful - in the right context).
My immediate reaction when faced with a SMAL program is to
get the assembler output and then convert that into 'real'
assembler code. SMAL just gets in the way of the underlying
machine - although you can write 'high-level' you still
have to know what's going on underneath (for example, you
have to know what instructions the SMAL is translated into
so that you can jump on the correct flag (carry, overflow,
etc)). Personally I think this is bad, and that a C and
assembler mix is a reasonable compromise between
development time, software quality, speed and codesize, and
so on.
Another favourite moan while I'm on the subject - I do hate
writing in (cross-) assembler under UNIX because the opcodes
and assembler format are always different from the
manufacturers. Anyone know whether this was done to avoid
copyright problems, to keep all the assemblers looking the
same, or just to discourage people from writing in low-level
languages?
--
Jonathan Clark
[NAC]!mtung!jhc
Ozan Yigit
>
>Please God save us from any more high-level assemblers, like
>SMAL, or PL/Z, or anything else (not macro assemblers,
>though. They are very useful - in the right context).
>
a package of structured macros. There is about ten of them
for PDP-11s. I have seen about three on VAX/VMS. That
is getting *high level*, wouldn't you say ???
>
>My immediate reaction when faced with a SMAL program is to
>get the assembler output and then convert that into 'real'
>assembler code. SMAL just gets in the way of the underlying
>machine - although you can write 'high-level' you still
>have to know what's going on underneath (for example, you
>have to know what instructions the SMAL is translated into
>so that you can jump on the correct flag (carry, overflow,
>etc)).
with the underlying machine, (Z80 in this case), and
it generates what it means. LOOP and IF-THEN structures
are straight forward, and no *secret* code is generated for
them. Even if the conveniences of LOOP and IF-THEN constructs
are not available, it seems to me that smal/80 style is better
than the ancient practice of creating assemblers with barely
understandable 3-5 character mnemonics. Naturally, 3-5 character
mnemonics are supposed to be "more efficient" to write for the
programmer. Think of how much time one spends in *commenting*
each and every line. (sigh!)
Oz (whizzard of something or another, no doubt..)
Usenet: [decvax|ihnp4|allegra|linus]!utzoo!yetti!oz
Bitnet: oz@yuleo | oz@yuyetti
Jonathan Clark
Oops. I was talking about an internal AT&T language called
SMAL/80, which is not and never will be a product. That does
have all the problems I was moaning about earlier. This
other SMAL/80 I have no experience with.