Aucbvax.1959 fa.info-micro utzoo!duke!decvax!ucbvax!CSTACY@MIT-AI Fri Jun 26 23:11:25 1981 INFO-MICRO Digest V3 #52 INFO-MICRO PM Digest Friday, 26 June 1981 Volume 3 : Issue 52 Todays's Topics: C - ESS Problems & Small C, 4Mhz H89s, Integrand 1100 Review, Unix-like Systems for Micros ---------------------------------------------------------------------- Date: 4 June 1981 01:38 edt From: Schauble.Multics at MIT-Multics Subject: C Language query This is the final answer to the query about the C language I put out LO these many months ago. Some people spoke to me more or less in confidence, so I will not credit any sources in order to protect them all. It turns out that the #5 ESS project indeed has development problems. Considering the size of the project this should not be surprising. The problems that were related to me fall into several catagories: 1. Usual large commercial development problems: It is a HUGE development with 1E6 programmers and almost as many managers. The design didn't quite provide all the detail the coders needed, and had the usual set of problems discovered during coding. The marketing people kept changing their minds about what it should do. And so on. Anyone who has every worked on a large commercial development project knows these problems. They are not unusual regardless of source language used. 2. High-level-language phobia This is the first major development done by this crew that has not been done in assembler. This has some people upset. There are always, it seems, some die-hard assembler fans (and they usually have some logic on their side). This problem, alas, is also not unusual on such first efforts. 3. Development environment. The usual resources problem. Most of the people have 300 baud printing terminals to work on. A fast terminal is a 1200 baud printer, and there aren't many of those. Since such equipment is not selected by people who have to use it, but by non-involved managers, this is also not a surprise. 4. Pointer arithmetic in C This is the only problem that referred to the C language directly. As it was explained to me, C does not contain a array as a language construct. Rather, instead of subscripts you do address arithmetic using pointers offset from a particular base. There is no conceptual problem here, but this does lead you to do a LOT of pointer arithmetic in the usual C program. The problem is: C was designed for a PDP-11. On this machine, a program consists of a read-only instruction region (max 64k bytes) and a data region (max 64 k bytes). Integers are 16 bits. The classic PDP-11 C compiler does not distinguish (within the compiler and code generator) between pointers and integers. Both are manipulated as 16 bit words using the 16 bit arithmetic instructions, and everything works fine. However, the #5 ESS uses 8086's as the CPU. This machine supports larger than a 64k byte region. In order to take advantage of this, pointers need to be 20 bits long. The 8086 has no 20 bit arithmetic instructions, they need to be simulated. This takes a lot of time and space. Couple this with the number of times they need to be generated leads to large, slow programs. 5. The excuse problem. Large development problems tend to run behind schedule. See reasons 1 to 4 above. Managers do not like to be blamed for this. To avoid blame, they will blame anything else, including the language being used. Now, I need to point out that I am not a C hacker. I have not yet written in the language at all. Thus, I am simply reporting the problems as my correspondants have reported them to me. I find all of the problems listed to be believable. Only one of them deals with the C language directly, and that only applies to machines that try to implement address spaces larger than can be handled in their integer size. I can believe that C is tied to 16 bit data/address machines since that is what it was designed for. That still is not a serious indictment of the language. In summary, it seems that while C has some problems for large systems development, these problems are no more severe than any other high level language, and may be less. Certainly the language is capable, given the proper support environment. As for the #5 ESS development, they were scheduled to begin operating their first system this year, and expect to make it. Thanks to thise who took the trouble to answer my query. I apologize for taking so long to make up this summary. Some things, it seems, have to wait for vacation to get done. Paul ------------------------------ From: Lauren at UCLA-SECURITY (Lauren Weinstein) Subject: C Just one point -- C does indeed have an array construct. Internally, array references may be translated to pointers, but programmers regularly work with N-dimensional arrays in a perfectly "normal" fashion. --Lauren-- ------------------------------ Date: 6 June 1981 18:21-EDT From: John C. Gilmore Does anyone have machine-readable copy of the "Small-C" compiler published in Dr. Dobb's Journal (May and Sept. 1980)? It compiled a subset of "big C" into 8080 assembler. I'd like to convert it, and improve the horrible quality of its output) for the 6502. ------------------------------ Date: 8 June 1981 00:06-EDT From: Patrick L. Harvey Subject: H/Z89 mods The data on 4Mhz H/Z89s is in the file: CPM; H/Z89 MODS [ This file may be FTPd from MIT-MC without logging in. -- CCS ] ------------------------------ Date: 29 May 1981 (Friday) 1413-PST From: DWS at LLL-MFE Subject: Review of the Integrand 1100 Mainframe Some months back I queried people about Integrand Mainframes. Many responded "let me know what you find out", so here goes ... This being my first system, I wanted to keep things relatively simple. This meant, to me, that lots of wiring was to be avoided. Hence all components, floppies included, should reside in the same box. A second consideration was to find a box that was aesthetically sound. I didn't want people pointing and saying "Look, a HOME COMPUTER!", rather, it should look like an extension of my home office furniture. After looking around for a bit I settled on the Integrand 1100, which seemed to fit the build. Unfortunatly I couldn't find one to look at up close, so I bought blind. Intergrand shipped in 5 weeks, it arrived at my doorstep last week, and I'm pleased. If you'll indulge me for a few moments of artwork, I'll try to show you what it looks like: 2 switched power 8 DB25 slots | fuse +-===-===----------=---------=-+ Cabinet size is 19w x 7.5h x 23d | | |----fan-----| Power supplies generate regulated | 7 slot |f| | power for drives, unregulated for | card |a| trans- | cards. All power cables supplied. | cage |n| former | Note that bus line 53 is grounded | - - - - - - - |-|------------| per IEEE spec. This is SSW DSB* |---+ +----| on some boards, and should be cut. | | power power | | Bus terminator kit is optional. | | supply supply | | | | for for | | ++-----------------------------++ | | disks cards +------| || O o || | | |------| ||-----------------------------|| |---+ +------| ||==============|==============|| |______________________________| || =o= | =o= || +----------------------=---=---+ ++-----------------------------++ reset power The mainframe is very solidly assembled out of rather hefty metal stock. The side pieces are wood grained formica over 3/4" pariticle board. Two Shugart 8xx floppies fit into the cabinet VERY snuggly, and once they are in and wired, and some cards are in and wired, there isn't very much room left inside. The fan on the side of the cardcage seems to keep the boards from getting much more than warm. Also, the fans are fairly quiet. What am I not happy about? Well, the card cage could have been built a tad bit better. The plastic removal tabs on the top corners of boards get wedged against one side of the cabinet, making things a bit sticky. Also, the DB25 slots are positioned a bit high, making it difficult to use the top two slots. A few more slots on the motherboard would be nice. For somebody trying to put together a "nice" looking system for office user, I would recommend the Integrand 1100. most biasedly yours, -- Dave Smith ------------------------------ ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.