jbn@wdl1.UUCP (05/15/85)
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
dgary@ecsvax.UUCP (D Gary Grady) (05/17/85)
> 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 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
jbn@wdl1.UUCP (05/24/85)
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.
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 Nagledarrelj@sdcrdcf.UUCP (Darrel VanBuer) (05/25/85)
I used PL/360 on my own for System Programming 10 years ago, but there were
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
VANBUER@USC-ECL.ARPAasente@Cascade.ARPA (05/28/85)
I feel obligated to defend Stanford, at least a little, after the following 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 asente@Cascade.ARPA
dgary@ecsvax.UUCP (D Gary Grady) (05/30/85)
John Nagle writes: > 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. -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
chuck@dartvax.UUCP (Chuck Simmons) (06/02/85)
> 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. > D Gary Grady 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
dgary@ecsvax.UUCP (D Gary Grady) (06/04/85)
> 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 > > Chuck Simmons 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... -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
oz@yetti.UUCP (Ozan Yigit) (06/10/85)
>Maybe what I should be squawking about is a better syntax for assembler >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