On the appropriate language for system programming

Fletcher, John G.; Badger, C. S.; Boer, G.L.; Marshall, G. G.

doi:10.1145/953360.953361

Cited by 4 publications

(1 citation statement)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The remainder of this paper focuses on this objective. While this approach does not currently enjoy universal support, it is interesting to note striking similarities to the debate over moving away from assembly language programming in the mid 1970s [26,27,28,38]. In that case increases in hardware and software complexity-alongside improvements in programming language technology-ultimately decided the issue, and we feel this will be the case again.…”

Section: Introductionmentioning

confidence: 95%

Demystifying magic

Frampton

Blackburn

Cheng

et al. 2009

Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments

View full text Add to dashboard Cite

The power of high-level languages lies in their abstraction over hardware and software complexity, leading to greater security, better reliability, and lower development costs. However, opaque abstractions are often show-stoppers for systems programmers, forcing them to either break the abstraction, or more often, simply give up and use a different language. This paper addresses the challenge of opening up a high-level language to allow practical low-level programming without forsaking integrity or performance.The contribution of this paper is three-fold: 1) we draw together common threads in a diverse literature, 2) we identify a framework for extending high-level languages for low-level programming, and 3) we show the power of this approach through concrete case studies. Our framework leverages just three core ideas: extending semantics via intrinsic methods, extending types via unboxing and architectural-width primitives, and controlling semantics via scoped semantic regimes. We develop these ideas through the context of a rich literature and substantial practical experience. We show that they provide the power necessary to implement substantial artifacts such as a high-performance virtual machine, while preserving the software engineering benefits of the host language.The time has come for high-level low-level programming to be taken more seriously: 1) more projects now use high-level languages for systems programming, 2) increasing architectural heterogeneity and parallelism heighten the need for abstraction, and 3) a new generation of high-level languages are under development and ripe to be influenced.

show abstract

Section: Introductionmentioning

confidence: 95%

Demystifying magic

Frampton

Blackburn

Cheng

et al. 2009

Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments

View full text Add to dashboard Cite

show abstract

Writing software in ALGOL

Brown¹

1974

Softw Pract Exp

View full text Add to dashboard Cite

For many years the Burroughs Corporation has been writing software in ALGOL. Those of us who have no direct access to Burroughs hardware have always regarded this with interest, perhaps with envy. Nevertheless most of us have been just a little sceptical, as witnessed by the fact that, until recently, few have followed or imitated Burroughs' example. Outsiders have their doubts about efficiency and wonder about such questions as: Is it really ALGOL? Is the technique oriented to a particular type of hardware? Are there some machine‐language ‘fiddles’? This paper is simply a description of a personal software experience. Recently I had an opportunity to spend some time as a user of a Burroughs B6700, and to write some software for it in ALGOL. This article combines a tutorial introduction with a personal evaluation.

show abstract

No! high level languages should not be used to write systems software

Fletcher¹

1975

Proceedings of the 1975 Annual Conference on - ACM 75

View full text Add to dashboard Cite

The views expressed here derive from the experience of the author and his colleagues in designing and implementing the Octopus computer network at the Lawrence Livermore Laboratory. This network serves five major time-shared computers (CDC 7600's and STAR-100's), connecting them to over 800 interactive terminals, about 200 television monitor displays, printers that operate at up to 18,000 lines/mlnute, and more than a trillion bits of storage. The software for the network has been written entirely in assembly language (for PDP-8's, 10's, and ll's, MODCOMP II's, and TI 980's) and from scratch, basing none of it on manufacturers' or other commercial software. The same persons who create the design also do the programming and debugging.In most cases one or two persons program a computer; four persons were used on the largest system (the PDP-10's).Our experience does not accord with much of what we read in the computing literature, leading us to conclude that it is written by persons unaware of the real problems of systems work. We have had little or no trouble with deadlocks, security loopholes, and other logical flaws that are belabored at length in the literature. Most of our effort has gone into devising ways for the system to survive in the presence of intermittent and random failures of hardware components and for it to maintain high data transfer rates among multiply-interconnected devices and computers of varying speeds, matters that are seldom discussed in the literature at all. It is certainly not the case that the difficulties encountered with operating systems are the same as those encountered with other large programs~ such as compilers.Our experience also contrasts with many of the assertions made about assembly language system programs: We do not find that they are more prone to bugs, are less clear or less well organized (structured), require a greater investment in time or money, or are less easy to modify. We can only suppose that findings to the contrary are saying something about the skills of the programmers involved rather than about languages. We are more confident of the correctness of our assembly language programs than we are of the correctness of most programs of comparable complexity.To clarify our position, we should point out that what we call system programs may be approximately characterized as those programs that execute in a privileged mode and perform those tasks that the security measures of the system should prohibit a user's program from directly performing for itself. They include i/o drivers, storage allocators, file accessors, process schedulers~ and interpreters of requests by user programs. They do not include any program that a user could write for himself, even though he usually does not, such as compilers, editors, information retrievers, debuggers, and other utilities which can (and should) *Work performed under the auspices of the Energy Research and Development Administration. 209execute in an unprivileged mode. The language that is best for such programs should be dec...

show abstract

On the appropriate language for system programming

Cited by 4 publications

References 1 publication

Demystifying magic

Demystifying magic

Writing software in ALGOL

No! high level languages should not be used to write systems software

Contact Info

Product

Resources

About