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 <GNU AT MIT-AI>
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 <HARV MIT-MC AT>
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 <
[email protected]>
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.
