Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/dist/info-kcc.mail
There are no other files named info-kcc.mail in the archive.
27-Jul-86 19:05:10-PDT,1316;000000000001
Mail-From: KLH created at 27-Jul-86 19:03:22
Date: Sun 27 Jul 86 19:03:17-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New list - INFO-KCC
To: info-kcc@SRI-NIC.ARPA
Message-ID: <12226156458.30.KLH@SRI-NIC.ARPA>
It was a lot of work, but KCC and its library are just about
ready for distribution; development will probably never finish, but
it's finished enough to start bundling things up.
The NIC has agreed to serve as the location for the canonical
sources and distribute copies as needed (via FTP or tape). To support
this, I have set up a new mailing list called INFO-KCC@SRI-NIC.ARPA
which is for KCC announcements and the like; every site that uses KCC
should have an address on this list if possible. Everyone who used to
be on BUG-KCC is now on INFO-KCC.
I have also set up a new bug list of KCC maintainers, called
BUG-KCC@SRI-NIC.ARPA, which is intended to be used for bug reports (of
course) and gory technical discussion that might scare people away
from INFO-KCC. Since I'm not sure who else is still interested in
this, the only two members at present are myself and Ian Macky
(IAN@SRI-NIC).
Another message will follow next week or so with more details.
In the meantime, send mail to INFO-KCC-REQUEST for the usual additions
and changes.
--Ken
-------
1-Oct-86 22:39:34-PDT,3609;000000000001
Mail-From: KLH created at 1-Oct-86 22:16:07
Date: Wed 1 Oct 86 22:16:02-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New KCC ready
To: info-kcc@SRI-NIC.ARPA
Message-ID: <12243493052.16.KLH@SRI-NIC.ARPA>
A new snapshot of KCC sources is finally ready. To retrieve the
files, use anonymous FTP to SRI-NIC.ARPA and FTP everything in the
directory that the logical name KCCDIST: points to. Note there are
several subdirectories.
Here is a summary of the new stuff, extracted from NEWS.TXT:
-----------------------------------------------------------------------
09/28/86 KCC 533, LIBC 14: <1,,1> Second formal distribution snapshot
This is called a "snapshot" to emphasize that while the sources
in this distribution should be consistent and working, the compiler and
library are still under active development to remove known quirks and
deficiencies, and have already changed.
As before, all .REL files must be recompiled; the STDIO
structures are different and there are new C runtime hooks. Most
importantly, the symbol $$CVER is now defined in every module
(currently it is <1,,1>) so as to detect any future conflicts when
loading modules that were incompatibly compiled.
Various change notes follow. For all of them, see the CC.DOC
file for more details.
KCC: ---------------------------------------------------------------
KCC - Command line
There are several new switches, and the way KCC interprets
filenames is slightly different. A file with a .REL extension is
always ignored, but is passed on to the loader. A file without any
extension is special if the -q switch is given; it is only compiled if
the .C source is more recent than the .REL binary.
New switches:
-A Specify nonstandard assembler header file (old meaning of -H)
-H Specify nonstandard path for #include <> files.
-i Loader: load program to run with extended addressing.
-L Loader: nonstandard path for library files.
-l Loader: search specified library
-o Loader: specify .EXE filename.
-P Set portability level.
-q Compile extension-less files conditionally.
KCC - General
There are no real changes in code generation. A couple of
over-optimization bugs were fixed, and a couple of other optimizations
added.
KCC now generates its own assembler header based on the target
CPU, assembler, and system; the file C-HDR.FAI no longer exists.
Two more KCC extensions were added: the `ident` quoting syntax,
and the asm() in-line code mechanism. #asm and #endasm must now appear
only within a function body.
KCC identifiers are now unique up to 31 characters, as per the
ANSI draft (external symbols are still only unique up to 6).
The runtime variable $EXADF no longer exists. The decision on
whether to run extended is now made at load time, either with the -i switch
or by loading C:LIBCKX as the first module.
LIBC: --------------------------------------------------------------
LIBC - CHAR
ispunct() was "fixed" to exclude space. CARM claims space is
included, but neither ANSI nor BSD does so. We assume this is a mistake
in CARM.
LIBC - STRING
The routines memchr, memcmp, memcpy, memset were added from ANSI.
LIBC - STORAGE
free(), malloc(), and realloc() now behave as per ANSI when given
NULL or zero as arguments.
LIBC - STDIO
The "update" mode is now supported for streams. In addition
to this, the library implements the ANSI concept of text vs binary
streams. The 'R' specification was flushed; 'b', '7', '8', '9', 'C',
and "C-" were added.
LIBC - other
system() was added.
-------
10-Feb-87 12:26:35-PST,3654;000000000001
Mail-From: KLH created at 10-Feb-87 12:24:47
Date: Tue 10 Feb 87 12:24:43-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Forthcoming KCC changes; comments?
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12277999337.15.KLH@SRI-NIC.ARPA>
First, the news. I am almost finished with a new version of KCC which
has some incompatible changes:
(1) Functions that return structures now operate differently.
(2) The "short" data type is now 18 bits (halfword) instead of 36.
(3) Structure/union members of type "char" and "short" are compacted.
(4) String literals are now normally 9-bit byte strings (not 7-bit).
and, of course, several improvements:
* Structure copying and returning is much more efficient, using in-line
BLT or XBLT and sometimes avoiding the stack altogether.
* Integer narrowing and widening is done properly in all situations.
* Pointer constant initialization happens at load time rather than
run time, reducing the size and startup overhead for C programs.
* Unsigned integer arithmetic is completely implemented.
And second, a request for feedback:
I'd like to propose an extension which recent internal changes
have now made possible, and see what you think. This extension would
amount to adding 5 new KCC-specific data types which would be called
"_KCCtype_charN" where N is one of 6, 7, 8, 9, or 18. These will act
exactly like "char" except that the bytesize would be N rather than
the default 9. Consider these declarations:
_KCCtype_char8 packet[40]; /* An array of 8-bit bytes */
_KCCtype_char7 *arg = "text"; /* A pointer to an ASCIZ string */
_KCCtype_char18 useless; /* Same as "short useless;" */
_KCCtype_char6 tmp[] = "tmp"; /* An array of SIXBIT chars */
In addition, there will be two special cases of interaction between these
types and string literals:
(1) A 6-bit string literal will be stored as SIXBIT rather than
using the low 6 bits of the ASCII char values.
This does not affect integer values stored into 6-bit arrays.
(2) A cast of a string literal to (_KCCtype_charN *) will be interpreted
as a request to use N-bit bytes in the literal, rather than
just operating on the pointer to the literal (the strict C
interpretation). For example,
(_KCCtype_char7 *)"text"
Will produce a 7-bit pointer to a 7-bit (ASCIZ) string.
Strict C would otherwise make a 7-bit ptr to a 9-bit string,
which is kind of useless.
Here are the pros and cons I could think of:
PRO:
* It will make it easier to write PDP-10 code which must
interface with the operating system or non-C software.
* It should be possible to completely flush the -x=ch7 switch,
which (in my opinion) has too much potential for trouble, as it
changes "char" to "_KCCtype_char7" EVERYWHERE, and certain things
cannot be made to work right.
CON:
* It may cause problems when porting code from elsewhere which
uses those identifiers.
* It may tempt some people to write non-portable code when
portable code would work just as well.
The last two points are the reason why the type names are
"_KCCtype_charN" instead of "charN". This almost eliminates the
chance of identifier conflict, and forces lazy people to think twice.
It also encourages them to use a #define or typedef instead (e.g.
"typedef _KCCtype_char7 char7;") which makes programs both more
readable and more amenable to porting.
I would like comments on this proposed extension. In particular I
need to hear from anyone who depends on -x=ch7, because I would like
to flush that switch altogether.
Thanks,
--Ken
-------
6-Mar-87 19:56:32-PST,6902;000000000001
Mail-From: KLH created at 6-Mar-87 19:41:56
Date: Fri 6 Mar 87 19:41:51-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New KCC is ready!
To: info-kcc@SRI-NIC.ARPA
Message-ID: <12284370371.19.KLH@SRI-NIC.ARPA>
Finally, after a lot of sweat and blood, a new KCC is ready
with all of the features previously mentioned, plus a few more. This
should be the last incompatible version for a long time, although new
(compatible) versions will continue to spring up. Even as you read
this, some sources will already have changed; there is still a long
list of good and interesting things to do. This snapshot has been
made following the dictum that "better is the enemy of good enough" --
a good distribution now is more useful than a better one later.
A new, consistent set of sources is available from the usual
place, the KCCDIST: directory on SRI-NIC.ARPA. Likewise, the latest
binaries (if that is all you want) are SYS:CC.EXE, C:<KCC>*.*.0, and
C:<KCC.SYS>*.*.0. While things have been pretty thoroughly tested
here, there is always a small possibility that new bugs will emerge
when presented with the outside world; please send any comments,
problems, and suggestions to BUG-KCC@SRI-NIC.ARPA.
Here follows the relevant excerpt from NEWS.TXT that
summarizes the changes:
-----------------------------
03/06/87 KCC 557, LIBC 124: <2,,1> Third formal distribution snapshot
IMPORTANT: this version of KCC is incompatible with previous
versions! The way that structures are returned from functions has
changed, and the layout of "char" and "short" objects in structures has
also changed. In order to enforce this, the symbol $$CVER has been
updated, and any attempt to load .REL modules which have been produced
by incompatible versions of KCC will cause LINK to complain with an
error message similar to this:
%LNKMDS Multiply-defined global symbol $$CVER
Detected in module PRINTF from file C:LIBC.REL
Defined value = 1000001, this value = 2000001
This is easily remedied by re-compiling old modules. Fortunately, no
further incompatible changes are expected to be necessary.
Nothing has really changed from the user's viewpoint. However,
there are several new features available, and some inefficiencies
corrected. The noteworthy changes are listed below, very briefly;
as usual, CC.DOC should be consulted for more complete and informative
details.
KCC: ---------------------------------------------------------------
KCC - Bug fixes:
A multitude of minor bug fixes too trivial to mention, almost
all having to do with incorrectly optimized code. One that wasn't
trivial was that {char c, *cp = &c;} used to produce an (int *)!
KCC - Incompatible changes:
* "shorts" are now 18 bits long (halfwords), with sizeof(short) == 2.
* The mechanism for returning structure values from functions
is different. This is an internal change, invisible to the user, which
is much more efficient than the previous method.
* Structure members of type "char" and "short" are now packed
differently (more compactly). Any structure using these types will be
laid out differently in storage.
* Integer narrowing and widening is now done properly in all
situations. This may cause incorrectly written code to behave
differently.
* Implicit arithmetic conversions now follow the ANSI
value-preserving rules rather than the old K&R and H&S
unsigned-preserving rules. Ambiguous code may behave differently.
* "float" values are no longer automatically converted to "double",
except for function arguments. This conforms to the ANSI draft.
* The "signed" keyword (introduced by ANSI) has been implemented.
* "volatile" and "const" (also new from ANSI) are now reserved
words (but unimplemented).
KCC - Extension: New data types:
5 new data types have been introduced, which act like "char"
but with different byte sizes. You can now manipulate signed or
unsigned bytes of 6, 7, 8, 9, or 18 bits. This is non-portable and
intended strictly for PDP-10 machine-dependent code where efficiency
is desirable.
KCC - Efficiency improvements:
The change to the structure handling mechanism falls in this
category. Structure copies used to always take two subroutine calls
and two copies; they now use a single in-line BLT (or a series of
single-word moves, whichever is best), and are much faster than
element-by-element copying.
KCC's constant initialization code has been improved to the point
where almost all constants are now initialized at load time rather than
at run time; a similar mechanism eliminates the code that used to generate
string constant pointers. You will see a significant difference with code
that uses many string literals; both startup time and program size are
reduced.
KCC's pointer arithmetic for byte pointers is MUCH better.
Pointer comparison and subtraction formerly used subroutine calls and
many, many instructions; both now use a handful of in-line
instructions and some magic numbers.
There are no more calls to internal run-time subroutines.
All of the operations which used to require this are now compiled
in-line, including double-int and int-double conversion, pointer
operations, and structure copying.
KCC - unsigned and signed data:
KCC now fully supports "unsigned int" operations. Some code
that uses unsigned integers will now compile differently. Division in
particular needs many more instructions. Any integer type, "char" in
particular, may be declared as "signed" and will behave accordingly.
KCC - Switch changes:
-L=<str> Passes <str> in the command string to the linking loader.
-v=<fs> (Verbosity) has been expanded; see CC.DOC. -v alone prints out
everything, including the loader command string.
-l Libraries loaded with the -l switch are now loaded in /SEARCH
mode (they evidently weren't before).
KCC - Miscellaneous
-d=sym now produces a *.CYM file instead of *.SYM, to avoid
conflicts with LINK output files.
-P=ansi+kcc is now the default. The effects are minor and documented
in CC.DOC. The three new ANSI keywords of "signed", "const", and "volatile"
are recognized, although only the first has any real effect.
LIBC: ---------------------------------------------------------------
More minor bug fixes to the LIBC stdio routines.
open() now attempts to track down and expand logical device
names completely (thus performing what the monitor should be doing but
isn't). Thus, open("X:subdir/filename.ext",0) will work even if X is
a search path. Previously only the first device/directory could be tried.
This permits KCC #includes to work with C: defined as a search path.
malloc() no longer allocates pages 770-777 (non-extended) or
37770-37777 (extended), so that obsolete forms of DDT can be mapped therein.
-------
17-Mar-87 09:08:21-PST,1782;000000000001
Received: from A20.CC.UTEXAS.EDU by SRI-NIC.ARPA with TCP; Tue 17 Mar 87 08:58:41-PST
Date: Tue 17 Mar 87 10:58:34-CST
From: Mic Kaczmarczik <Cc.Kaczmarczik@A20.CC.UTEXAS.EDU>
Subject: Internal register allocation errors
To: info-kcc@SRI-NIC.ARPA
Message-ID: <12287136847.22.CC.KACZMARCZIK@A20.CC.UTEXAS.EDU>
Last night I was using the new distribution of KCC (announced in early
March) to recompile some code that had compiled fine using the old
version (ca. a month ago). Can anybody give me a clue as to what's
going wrong here? Since the source is about 30K bytes in all, I'm not
including it in this message, but will send it to any wizard willing
to look into the problem.
Thanks,
Mic Kaczmarczik
User Services Digital Support Group
U.T. Austin Computation Center
cc.kaczmarczik@a20.cc.utexas.edu
----------------------------------------------------------------------
[PHOTO: Recording initiated Tue 17-Mar-87 10:50AM]
Link from CC.KACZMARCZIK, TTY 112]
2a20 @ sys:cc -c -Imgsrc: buffer.c
KCC: buffer
Warning at killbuffer+66, line 161 of buffer.c:
savebuffers(
Internal error - Register allocation: unreleased registers left over from previo
us code
Warning at killbuffer+66, line 161 of buffer.c:
savebuffers(
Internal error - Register allocation: release of a spilled register
Warning at killbuffer+66, line 161 of buffer.c:
savebuffers(
Internal error - Register allocation: release of a spilled register
Warning at showbuffer+45, line 469 of buffer.c:
WINDOW
Internal error - Register allocation: unreleased registers left over from previo
us code
<CC.KACZMARCZIK.MG>BUFFER.PRE.1
<CC.KACZMARCZIK.MG>BUFFER.FAI.1
FAIL: buffer
2a20 @ pop
[PHOTO: Recording terminated Tue 17-Mar-87 10:50AM]
-------
17-Mar-87 20:51:56-PST,811;000000000001
Mail-From: KLH created at 17-Mar-87 20:48:02
Date: Tue 17 Mar 87 20:47:56-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC 560 - new version with bugfixes
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12287265984.17.KLH@SRI-NIC.ARPA>
A new version of KCC has been installed as SYS:CC.EXE on SRI-NIC.ARPA.
This corrects all of the minor bugs that users have discovered in the
most recent distribution, including unnamed bitfield positioning,
"register allocation" warnings, and more peephole optimizer bulletproofing.
A few additional minor optimizations are now done, but otherwise there
are no changes.
A reminder: send bug reports to BUG-KCC@SRI-NIC.ARPA (the maintainer/hacker
list), not to INFO-KCC (the global news list). Thanks for the reports
so far!
-------
18-Mar-87 14:36:54-PST,1870;000000000001
Mail-From: KLH created at 18-Mar-87 14:22:05
Date: Wed 18 Mar 87 14:17:46-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: [Ken Harrenstien <KLH@SRI-NIC.ARPA>: New H&S edition of CARM!]
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12287457101.14.KLH@SRI-NIC.ARPA>
Here's a copy of a message I just sent elsewhere:
Date: Wed 18 Mar 87 14:09:07-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New H&S edition of CARM!
To: info-c@BRL.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12287455526.14.KLH@SRI-NIC.ARPA>
Haven't seen any other mention of this, so thought I'd spread the
word; I wish I had known about it earlier myself.
I just discovered by accident that the second edition of Harbison and
Steele's "C: A Reference Manual" is now out in the stands!
Unfortunately, it also seems to be out of stock -- the first 4
bookstores I tried had completely run out of their initial orders
(they seemed quite bemused by its popularity), and all had additional
shipments on the way. I did manage to find one place (would you
believe the Stanford campus bookstore??) that still had a handful
left, and grabbed one. It's much heftier, costs $25, and the back
cover blurb claims it includes a description of the draft ANSI C
language. I haven't looked at it yet, but am confident that it will
be the definitive reference for C until the ANSI draft becomes a
standard (which may not be for a while).
--Ken
-------
I mention this here because KCC is supposed to be a full
implementation of H&S CARM, and I want to continue keeping it that
way. A close perusal of the second edition will be needed before we
can say what (if any) changes might be necessary or advisable; if
there are changes they will be announced, of course. Feel free to
make suggestions if you have some (to BUG-KCC@SRI-NIC.ARPA).
-------
19-Mar-87 23:41:51-PST,2458;000000000001
Mail-From: KLH created at 19-Mar-87 23:38:32
Date: Thu 19 Mar 87 23:38:28-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Floating-point questions
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12287821317.25.KLH@SRI-NIC.ARPA>
ANSI EXTENSION - "long double" type
The ANSI draft standard (X3J11) proposes a new float data type
called "long double" which is expected to have precision/range at
least as great as "double": float <= double <= long double. The need
to assign some hardware format to this new type raises the issue of
the most suitable mapping for all three types, and I'd like some comments
on this.
The PDP-10 floating point formats are:
Words Precision (digits) Range
"F" Single-precision 1 8 1.5e-39 to 1.7e38
"D" Double-precision 2 18 1.5e-39 to 1.7e38
"G" format 2 17 2.8e-309 to 9.0e307
The single-precision "F" format has been around since day one on the
PDP-6. Hardware double-precision ("D") was introduced on the KI-10
(the KA-10 uses a different software format for double precision). G
format is a new one only available in KL10s with microcode version 271
or up; KS10s (DEC-2020) don't have this. Note the loss of
significance is exchanged for a gain in range.
The plausible mappings appear to be:
Float Double Long Double
A. F F D Fast arith, all CPUs (or non-KL)
B. F F G Fast arith, KL only
C. F D D All CPUs (or non-KL)
D. F D G KL only
E. F G G KL only
C considerations:
C according to H&S requires that all operands of type "float"
be converted to "double". ANSI C will permit them to remain "float",
however. All C library routines, both now and in the future, require
"double" arguments and return "double" results.
Timing considerations:
I ran some timing tests on SRI-NIC (a DEC-2065) and have summarized
the results in this table (times are in usec):
ADD SUB MUL DIV
Single 1.9 2.2 2.5 4.6
Double 2.5 3.2 4.2 8.7
G-fmt 7.5 8.2 5.8 9.8
Exact times will depend on the operands used; the values chosen were
picked to give a reasonable number of bit transitions. Note the much
larger times for G format arithmetic.
I would like to hear any comments about the most suitable mapping to
use. If no one says anything, I will probably decide to simply keep
the current setup ("float" is F, "double" is D), and make "long
double" correspond to G format on KLs, D format otherwise.
-------
21-Mar-87 16:55:55-PST,1252;000000000001
Mail-From: KLH created at 21-Mar-87 16:41:28
Date: Sat 21 Mar 87 16:41:22-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Addendum on "long double"
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12288269675.25.KLH@SRI-NIC.ARPA>
A couple of concerned responses have shown me that I could have
avoided some confusion by explaining how "long double" is expected
to interact with library routines.
The CURRENT library routines all expect their floating-point arguments
to be "double", and return floating-point values as "double". This
will not change. I mentioned this consideration to point out how
heavily used the "double" format is.
In order to handle the "long double" data type, the ANSI draft proposal
specifies that a 'L' prefix be used in fscanf and fprintf format strings
to indicate the argument is of type "long double". The math library
routines are expected to be expanded to provide duplicate versions of
all functions, by prefixing 'f' for "float" routines and 'l' for "long
double" routines. They have not yet followed up on this "future direction",
as far as I know, but at least they are aware that this is necessary.
Coming up... a new question about multi-char constants.
-------
21-Mar-87 17:10:51-PST,1420;000000000001
Mail-From: KLH created at 21-Mar-87 16:59:18
Date: Sat 21 Mar 87 16:59:14-PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Multi-char constant format?
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12288272928.25.KLH@SRI-NIC.ARPA>
Paragraph quoted from H&S v2, 2.7.3:
" Most computers represent integers in a storage area big enough
to hold several characters, and so many C compilers allow
"multicharacter" constants, such as 'ABC'. The intent is to create an
integer value (not a string) from the characters. The use of this
feature, if available, can result in portability problems, not only
because integers have different sizes on different computers but also
becaue computers differ in their "byte ordering", that is, the order
in which characters are packed into words. Given the constant 'ABC',
some computers would put 'A' in the low-order bits and others would
put 'A' in the high-order bits. Draft Proposed ANSI C permits
multicharacter constants but leaves their value up to the
implementation. "
As you might guess, the question is: should KCC permit this,
and if so, how should 'ABC' be formatted into a 36-bit PDP-10 word? I
would not advise anyone to ever write anything using this "feature",
which is the more pernicious for its being pseudo-legal C, but given
that the parser should accept it, what is the best meaning to assign
to it?
-------
23-Mar-87 08:40:14-PST,668;000000000001
Received: from UTAH-SCIENCE.ARPA by SRI-NIC.ARPA with TCP; Mon 23 Mar 87 08:25:09-PST
Date: Mon 23 Mar 87 09:23:51-MST
From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
Subject: Re: Multi-char constant format?
To: KLH@SRI-NIC.ARPA, info-kcc@SRI-NIC.ARPA
cc: Beebe@UTAH-SCIENCE.ARPA
In-Reply-To: <12288272928.25.KLH@SRI-NIC.ARPA>
X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <12288703393.41.BEEBE@UTAH-SCIENCE.ARPA>
I vote against it. Initializations of words are already
adequately supported by decimal, octal, and hexadecimal
constants.
-------
11-May-87 18:18:57-PDT,443;000000000001
Mail-From: KLH created at 11-May-87 18:14:20
Date: Mon 11 May 87 18:14:17-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New CC.EXE available
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12301645011.18.KLH@SRI-NIC.ARPA>
A new version (561) of SYS:CC.EXE has been installed at SRI-NIC and can be
FTP'd. This mainly fixes a couple more unusual optimization bugs, and
is not a new source distribution.
-------
27-May-87 01:11:09-PDT,499;000000000001
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Wed 27 May 87 00:58:16-PDT
Date: Wed 27 May 87 00:57:59-PDT
From: David Roode <ROODE@BIONET-20.ARPA>
Subject: KCC Libraries
To: info-kcc@BIONET-20.ARPA, bug-kcc@BIONET-20.ARPA
cc: Golub@BIONET-20.ARPA
Phone: (415) 962-7322
Message-ID: <12305650663.15.ROODE@BIONET-20.ARPA>
1) Is there a screen management, forms, or display package for
KCC?
2) Is there a sharable runtime segment such as SAIL or PASCAL
has for KCC?
-------
27-May-87 08:52:17-PDT,887;000000000001
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Wed 27 May 87 08:47:46-PDT
Date: Wed 27 May 87 09:48:17-MDT
From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: Screen management
To: roode@BIONET-20.ARPA
cc: BEEBE@SCIENCE.UTAH.EDU, INFO-KCC@SRI-NIC.ARPA
X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <12305736278.21.BEEBE@SCIENCE.UTAH.EDU>
Volume 1 of mod.sources (available at SEISMO for FTP) has
PCURSES, a public-domain version of CURSES, which is
probably the best way to go now for screen management, since
it is available on all Unix systems, in VAX VMS C, and at
least 2 commercial (~$125) versions on the IBM PC (see the
June 87 issue of Computer Language, p. 144). PCURSES needs
sgtty.h, which KCC does not yet have, but may soon.
-------
28-May-87 15:17:21-PDT,928;000000000001
Mail-From: KLH created at 28-May-87 15:15:44
Date: Thu 28 May 87 15:15:20-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: KCC Libraries
To: ROODE@BIONET-20.ARPA
cc: Golub@BIONET-20.ARPA, KLH@SRI-NIC.ARPA, info-kcc@SRI-NIC.ARPA
In-Reply-To: <12305650663.15.ROODE@BIONET-20.ARPA>
Message-ID: <12306068881.50.KLH@SRI-NIC.ARPA>
To add to Nelson's reply: we are working on s/gtty() and ioctl() now, so
it shouldn't be long.
As for the idea of using a sharable runtime segment for the library routines,
this notion has been entertained for a while but the mechanics have yet to
be worked out; the library itself is changing all the time. It has been
suggested that we find a way to use the FORTRAN runtime library for access
to their versions of various math functions; doing both at once would be
an interesting problem. If you have a specific proposal to contribute,
please get in touch...
-------
28-May-87 15:47:04-PDT,1823;000000000001
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Thu 28 May 87 15:42:23-PDT
Date: Thu 28 May 87 15:42:13-PDT
From: David Roode <ROODE@BIONET-20.ARPA>
Subject: Re: KCC Libraries
To: KLH@SRI-NIC.ARPA
cc: Golub@BIONET-20.ARPA, info-kcc@SRI-NIC.ARPA
In-Reply-To: <12306068881.50.KLH@SRI-NIC.ARPA>
Phone: (415) 962-7322
Message-ID: <12306073776.32.ROODE@BIONET-20.ARPA>
DEC-20 FORTRAN has both a sharable segment and an object library.
FOROTn.EXE (46 disk pages where n=7) is the sharable segment and
FORLIB.REL (133 disk pages for v. 7) is the object library. The
tradeoff I think was to preserve address space in the case where not
everything in the runtimes is needed in a particular program. The
disk page sizes are a reasonable estimate of the address space that
would be consumed. PASSEG.EXE is 58 pages and T-6-SAISEG9.EXE is 46
pages.
Unfortunately I think the math routines are in FORLIB.REL and don't
really belong in a shared segment for KCC. The real basic runtimes to
the tune of 50 pages or so make a lot of sense for inclusion in that
fashion. Typical user programs might take 10-20 disk or memory pages
and you cut down the disk space for the .EXE file by a large
percentage by having them map in the shared segment, not to mention
the paging space if a lot of such programs are in use on a given
machine.
You might look at a 2nd sharable segment which KCC optionally
maps in if several of the numerical routines are called. This
sounds hairy to me. It makes sense for this to be optional
if the user prefers to load what he needs from FORLIB directly
so minimize the impact on address space. Again the real
efficiency bought by this is if 20 people on the same machine
are running different images each of which have large parts
of FORLIB in them.
-------
8-Jul-87 11:11:08-PDT,1176;000000000000
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 11:08:38-PDT
Date: Wed 8 Jul 87 11:07:44-PDT
From: ELLIS E. GOLUB <GOLUB@BIONET-20.ARPA>
Subject: TERMINAL PAUSE and printf
To: INFO-KCC@BIONET-20.ARPA
cc: golub.ross@BIONET-20.ARPA, GOLUB@BIONET-20.ARPA
Message-ID: <12316771711.46.GOLUB@BIONET-20.ARPA>
I have experienced strange behavior by a program which outputs to the
terminal, when TERMINAL NO PAUSE END-OF-PAGE is in effect. Under
these conditions, some output is lost, while output from later
sections of the program begins inappropriately early. The same program
and data produce perfect output when the TERMINAL PAUSE option is
used. Initially, the output was generated by printf("\n.....
statements. When these gave poor results, I tried the \n at the end
of the line. When this failed, I tried fprintf(stdout,"...., and when
that failed, I tried sprintf(buffer,".... followed by
printf("%s\n",buffer). All of these attempts gave similar results.
Has anyone experienced similar problems, or does anyone have a fix
that eliminates this annoying bug?
Ellis Golub
U. Penn.
(215) 661-3269
-------
8-Jul-87 11:40:37-PDT,893;000000000000
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 11:30:53-PDT
Received: from SRI-NIC.ARPA by BIONET-20.ARPA with TCP; Wed 8 Jul 87 11:30:35-PDT
Date: Wed 8 Jul 87 11:29:36-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: TERMINAL PAUSE and printf
To: GOLUB@BIONET-20.ARPA, INFO-KCC@BIONET-20.ARPA
cc: golub.ross@BIONET-20.ARPA, KLH@SRI-NIC.ARPA
In-Reply-To: <12316771711.46.GOLUB@BIONET-20.ARPA>
Message-ID: <12316775693.17.KLH@SRI-NIC.ARPA>
Please send bug reports to BUG-KCC@SRI-NIC.ARPA. INFO-KCC is not a
bug reporting list and reaches many people who are not interested in
those reports. For this case, I suggest you also contact Rusch,
Relph, and Dautricourt at BIONET. Last I heard they were still using
a fairly old release of KCC, although it's hard to see how program
behavior could change just due to the TER PAUSE setting.
-------
15-Sep-87 15:49:15-PDT,3850;000000000000
Mail-From: KLH created at 15-Sep-87 15:47:30
Date: Tue, 15 Sep 87 15:47:22 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New KCC and LIBC binaries available
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12334910553.18.KLH@SRI-NIC.ARPA>
The new version of KCC (and its runtime library, LIBC) is now
available for people who want to try it out in binary form. After
waiting a while longer to see what bugs get shaken out, we'll put
together another snapshot of the sources and call that the KCC-4
distribution. Please send all bug reports to BUG-KCC@SRI-NIC.ARPA.
To get the new stuff, FTP these files from SRI-NIC.ARPA:
SYS:CC.EXE.0 (SYS:CCX.EXE if you want the extended-addr version)
C:*.*.0
PS:<KCC.SYS>*.*.0
You cannot simply get LIBC.REL from C: because many of the existing .H
files have been changed, and there are new additional files. So you will
have to copy everything.
Here is an extract from NEWS.TXT that describes what's new about this version:
---------------------
The bad news is that this release is incompatible enough with
the previous versions that you will have to recompile everything you
want to link together. This is mainly because the format of jmp_buf
(used by setjmp and longjmp) had to be expanded. As long as this had
to happen, a few other structures were expanded too. The $$CVER symbol
was updated to force LINK errors on any attempts to load incompatibly
compiled code.
The good news is that this version should completely implement all
facilities described by the new 2nd edition of Harbison and Steele's "C: A
Reference Manual". Some new system calls are also included.
KCC:
Few changes, mostly bug fixes. The __DATE__ and __TIME__ macros
have been implemented, which expand into the date and time of compilation.
LIBC:
Major changes. Many new functions were added. In particular,
signals now work, which required some revamping of the Un*x system
call (USYS) simulation routines. The following are the additions of
note:
longjmp/setjmp now act like CARM/4.3BSD and can restore context
properly even from within a signal handler.
The signal mechanism is intended to fully simulate 4.3BSD
sigvec, including the functions sigvec, sigblock, sigsetmask,
sigpause, sigreturn. All TOPS-20 PSIs are provided for. USYS calls
are handled atomically except when doing monitor calls; those which
are allowed to be interrupted will return EINTR errors.
Some new ANSI functions were added to STDIO. These include
setvbuf, remove, rename, tmpfile, tmpnam, v[fs]printf.
Some new general ANSI utilities were added, including bsearch,
div, ldiv, strtod, strol, strtoul, onexit, strerror, clock, mktime.
The time functions were completed and made portable.
Several miscellaneous functions described in CARM (most from
SYSV) were added, including ctermid, cuserid, getcwd, getenv, putenv,
getlogin, getopt.
A new "system call" was provided: forkexec(), which combines
the functions of fork() and exec() in a way which is extremely efficient
for TOPS-20 (and still portable to Un*x systems). The system() routine
now uses this, as does the runtime when forking pipes.
The jsys() routine was redone to provide a consistent interface
regardless of how the actual jsys returns success or failure. It also
provides an indication of whether the jsys was interrupted, if this
was permitted for the call.
Most important TTY ioctl() functions are now supported.
This includes the ability to set the SIGINT and SIGQUIT interrupt
characters. RAW and CBREAK mode are implemented.
There are some new documentation files. LIBC.DOC and USYS.DOC
summarize the library routines in general and the USYS calls in
particular; SIGNAL.DOC provides more details on the KCC implementation
of signals.
-------
19-Nov-87 21:40:10-PST,1266;000000000000
Received: from CU20B.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 21:38:12-PST
Date: Fri 20 Nov 87 00:37:31-EST
From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>
Subject: Linking assembler subroutines with KCC programs
To: info-kcc@SRI-NIC.ARPA
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <12352024579.10.SY.KEN@CU20B.COLUMBIA.EDU>
I'd like to be able to write an entirely separate assembler subroutine (in
MACRO) to be linked in with some KCC modules, and not have to use asm() if
possible. I have been fairly successful at getting this to work, except
that I would like to force the code to be placed in the TEXT segment. Is
there a way to do this? /Ken
P.S. -- If I let LINK put my MACRO module wherever it wants to, it will
stick it in the low segment (start address 140), which apparently blows
away some data that printf wants -- anyway, printf acts strangely. I've
forced the module to live at some hard address with LOC, but there must be
a better way.
P.P.S. -- Using the #asm/#endasm constructs, the right thing almost
happens. If I try to force the data storage in the MACRO source into the
DATA segment with %%DATA, the unpredictable printf behavior occurs again.
-------
20-Nov-87 02:35:17-PST,536;000000000000
Mail-From: KLH created at 20-Nov-87 02:33:35
Date: Fri, 20 Nov 87 02:33:28 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: Linking assembler subroutines with KCC programs
To: sy.Ken@CU20B.COLUMBIA.EDU, info-kcc@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <12352024579.10.SY.KEN@CU20B.COLUMBIA.EDU>
Message-ID: <12352078455.17.KLH@SRI-NIC.ARPA>
You should be addressing BUG-KCC@SRI-NIC.ARPA, not INFO-KCC (which is mainly
for news dissemination). I will respond to your question in a separate message.
-------
14-Mar-88 03:21:40-PST,1957;000000000000
Mail-From: KLH created at 14-Mar-88 03:16:31
Date: Mon, 14 Mar 88 03:16:22 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: New KCC binary available
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12382232826.25.KLH@SRI-NIC.ARPA>
My workload has eased up a bit and I'm now able to give a little more
attention to KCC. A new KCC binary (version 586) is available for
FTPing from SRI-NIC.ARPA. (Filename "SYS:CC.EXE", or "SYS:CCX.EXE"
for the extended version.) This primarily fixes a number of bugs that
have been reported recently, including:
(Bowman) sizeof of an array within a structure was wrong.
(KLH) Null statement in switch() was interpreted as break.
(Wancho) Yet another peephole optimizer bug.
(Beebe) Macro definition mistakenly collapsed blanks
within a string literal.
(Beebe) Macro invocations now treat newline as ordinary
whitespace (H&S was unclear on this).
(Wancho) Undefined identifiers in #if and #elif now have the value 0,
(as per ANSI) with a warning.
(KLH) Constant expression optimization was improved.
There are no currently outstanding bugs with the KCC compiler that I
am aware of. There are a few requested features that I will add in the
future as time permits, such as version numbering, PSECT support, and
the like.
The current C library (C:LIBC.REL) also has a couple of minor fixes,
notably a bugfix to system(). There are a few pending possible bugs
that I have yet to look into (mostly from Frank Wancho!) Once I have
done this and made any necessary changes to the documentation files, I
will finally put together the source release. This will include a new
library, LIBTMX, that provides portable date and time parsing routines
(no more IDTNC% needed). I have not been very successful with my time
estimates in the past, but I'll try again: if no new problems turn up
then things should be ready before the end of March.
--Ken
-------
24-Mar-88 12:34:26-PST,497;000000000000
Received: from TOPS20.DEC.COM by SRI-NIC.ARPA with TCP; Thu 24 Mar 88 12:30:34-PST
Date: 24 Mar 1988 1530-EST
From: "Andy Puchrik" <PUCHRIK@TOPS20.DEC.COM>
To: info-kcc@sri-nic.arpa
DTN: "297-7157 (617-467-7157)"
Loc/MS: "MRO1-2/L14 (Pole M13)"
Subject: monsym_*.h
Message-ID: <"MS11(6040)+GLXLIB6(0)" 12384955091.24.321.180267 at TOPS20.DEC.COM>
Where does one find the files monsym_[c,f,g,m,p,r,s].h? I'm trying to
compile system.c of the make utility.
Thanks,
asp
--------
24-Mar-88 12:39:13-PST,531;000000000000
Mail-From: KLH created at 24-Mar-88 12:36:27
Date: Thu, 24 Mar 88 12:36:13 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: monsym_*.h
To: PUCHRIK@TOPS20.DEC.COM, info-kcc@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <"MS11(6040)+GLXLIB6(0)" 12384955091.24.321.180267 at TOPS20.DEC.COM>
Message-ID: <12384956183.14.KLH@SRI-NIC.ARPA>
Check with the author, Nelson H.F. Beebe (Beebe@SCIENCE.UTAH.EDU).
Bug reports and the like should be addressed to BUG-KCC@SRI-NIC rather
than INFO-KCC, by the way.
-------
20-Apr-88 07:52:20-PDT,4147;000000000000
Mail-From: KLH created at 20-Apr-88 07:50:15
Date: Wed, 20 Apr 88 07:50:05 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC-5 now available!
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12391971060.28.KLH@SRI-NIC.ARPA>
The latest KCC sources are now (finally -- gasp) available in a new
distribution, KCC-5. People with FTP access to SRI-NIC.ARPA should, as
usual, retrieve everything in the directory that KCCDIST: points to,
which is now <KCC-5>. If you need help, first try retrieving the files
KCCDIST:OBTAIN.DOC and KCCDIST:INSTAL.DOC.
People without FTP access should contact me directly about getting a new
tape sent. They can also get a little more information by sending a message
to SERVICE@SRI-NIC.ARPA with the string "SEND KCCDIST:OBTAIN.DOC" in the
subject field.
Here is a summary of what's new, taken from the NEWS.TXT file. Note
that if you never got a binary version of the KCC-4 distribution (it was
never released in source form) then there are a great many more
improvements you are missing.
Enjoy!
--Ken
---------------------------
04/20/88 KCC 599, LIBC 219: <2,,2> Fifth formal distribution snapshot
General:
Several new routines, features, and packages have been added.
The various *.DOC files have been improved somewhat, and as usual there
have been some bug fixes both to KCC (primarily the optimizer) and the
library.
KCC:
As KCC sees wider and heavier use, progressively more obscure
over-optimization bugs get shaken out. The arcane details are
unsuitable for listing here, but many thanks are due to those people who
found and reported them!
In addition to bug fixes, some internal cleanup was done to
improve constant folding, regain more stack space, and remove the
previously fixed limitation on parse tree size. Most of these changes are
not externally visible, but some that are:
Error message output has been improved. Although little mousy
errors still tend to panic KCC into a long series of hysterical
screams, the messages themselves are more compact, more informative, and
more well-structured.
__COMPILER_KCC__ now exists as the sole KCC-dependent predefined
macro, so that portable programs can readily determine whether
KCC's <c-env.h> file, in particular, is available or not.
The entry vector is now 3 words to allow for a binary
version number to be put in the 3rd word.
Of great interest to systems programmers will be two new
built-in functions, _KCCsymfnd and _KCCsymval, which can obtain constant
symbol values from .UNV files at compile time. <monsym.h> uses them to
provide a macro which gives very efficient access to all monitor
symbols.
KCC now has an "-i=psect" switch to provide rudimentary support
for loading PSECT code.
LIBC:
The C startup code now recognizes arguments of the form "@file" as
being indirect file specifications; the file is read and parsed into further
arguments. This applies to all C programs including KCC, and provides a way
of getting around RSCAN buffer size limitations.
modf() was changed to conform to the description in V7, ANSI,
and BSD; the description in H&S (CARM) appears to be wrong.
The O_SYSFD flag was added to open(), to allow opening a FD with
an existing JFN.
open() has been changed so that when opening a new file for
writing, it actually does an immediate CLOSF% and another OPENF%. This
ensures that the file immediately exists and is visible, thus avoiding
a number of problems (invalid simultaneous access, file busy, etc) that
are hard to deal with otherwise. The side effect of this is that if
the process is killed before it finishes, its output files will exist
with zero length, whereas before they would not exist at all.
printf(), fprintf() and sprintf() now finally return the number
of characters they output; this will be -1 if an error occurred.
The Un*x functions isatty() and ttyname() are provided.
The TERMCAP functions now exist as LIBTRM.
Fully portable time parsing and manipulation routines are
provided in LIBTMX; see LIBTMX.DOC.
---------------------------
-------
26-Apr-88 18:44:10-PDT,730;000000000000
Mail-From: KLH created at 26-Apr-88 18:42:47
Date: Tue, 26 Apr 88 18:42:40 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC 601 available
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12393662721.40.KLH@SRI-NIC.ARPA>
Just a minor optimization bug fix. Since this came up so soon after
putting together the KCC-5 release, I took the time to retrofit the
changes into the source distribution.
I also added one new file, "KCCDIST:-FTP-.MIC", which is intended to
make it easier for people to FTP things. Get that file first, edit it
as necessary, and execute it to get the rest.
If you don't want sources, all you need to update from version 599 is
SYS:CC.EXE (and/or CCX.EXE).
-------
29-Apr-88 17:49:52-PDT,1187;000000000000
Mail-From: KLH created at 29-Apr-88 17:47:09
Date: Fri, 29 Apr 88 17:21:43 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC 602
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12394434417.40.KLH@SRI-NIC.ARPA>
Another optimization bugfix (glitch when optimizing some exprs of the form
array[0][x]). Since the source change is trivial I'm including it to
reduce overhead for people who maintain sources. Binaries available as
usual.
;COMPARISON OF PS:<C.KCC.CC>CCFOLD.C.115 AND PS:<C.KCC.CC>CCFOLD.C.116
;OPTIONS ARE /3
**** FILE PS:<C.KCC.CC>CCFOLD.C.115, 7-209 (19134)
&& e->Nright->Niconst == 0) /* (because 0+e already commuted) */
return e->Nleft; /* Won, e+0 or e-0 !! */
**** FILE PS:<C.KCC.CC>CCFOLD.C.116, 7-209 (19134)
&& e->Nright->Niconst == 0) { /* (because 0+e already commuted) */
/* Won, e+0 or e-0 !! But beware of funny array type conversion
** sometimes applied to plus/minus pointer arithmetic; result type
** may not be same as operand type. Keep result type.
*/
e->Nleft->Ntype = e->Ntype; /* Propagate result type */
return e->Nleft;
}
***************
-------
29-Jul-88 17:53:56-PDT,858;000000000000
Mail-From: KLH created at 29-Jul-88 17:49:34
Date: Fri, 29 Jul 88 17:49:27 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC 605 - bug fix
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12418294569.26.KLH@SRI-NIC.ARPA>
A minor optimization bug fix. New binaries in SYS:CC.EXE and SYS:CCX.EXE
on SRI-NIC. A diff follows for those with sources (foldjump() in CCJSKP.C):
;COMPARISON OF PS:<C.KCC.CC>CCJSKP.C.99 AND PS:<C.KCC.CC>CCJSKP.C.101
;OPTIONS ARE /E /3
**** FILE PS:<C.KCC.CC>CCJSKP.C.99, 9-50 (18281)
} else if (isskip (q->Pop) && b->Pop == P_JRST && b->Pptr == lab &&
invskip (before (b))) {
/*
**** FILE PS:<C.KCC.CC>CCJSKP.C.101, 9-50 (18281)
} else if (isskip(q->Pop) && oneinstr(q)
&& b->Pop == P_JRST && b->Pptr == lab
&& invskip(before(b))) {
/*
***************
-------
3-Aug-88 17:45:02-PDT,1311;000000000000
Mail-From: KLH created at 3-Aug-88 17:40:21
Date: Wed, 3 Aug 88 17:40:14 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC 606 - bug fix
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12419603613.31.KLH@SRI-NIC.ARPA>
Another minor optimization bug fix. New binaries in SYS:CC.EXE and
SYS:CCX.EXE on SRI-NIC. A srccom follows for those with sources:
(Function hackstack() in CCOPT.C, with cosmetic-only changes removed)
;COMPARISON OF PS:<C.KCC.CC>CCOPT.C.324 AND PS:<C.KCC.CC>CCOPT.C.325
;OPTIONS ARE /3
**** FILE PS:<C.KCC.CC>CCOPT.C.324, 13-161 (58074)
/* Instruction's E uses stack reg as index. Check the reference. */
**** FILE PS:<C.KCC.CC>CCOPT.C.325, 13-176 (58991)
/* Check for generating an auto variable address. Of the ops
** we recognize, only three things (XMOVEI, MOVE, ADJBP) should
** be able to generate such addresses.
*/
if (stackrefs) {
if ((p->Pop&POF_OPCODE) == P_MOVE
&& ((p->Ptype&PTF_IMM) /* XMOVEI */
|| ((p->Ptype&PTF_ADRMODE)==PTA_BYTEPOINT))) /* MOVE R,[bp] */
return 0;
if ((p->Pop&POF_OPCODE) == P_ADJBP
&& (p->Ptype&PTF_ADRMODE)==PTA_BYTEPOINT) /* ADJBP R,[bp] */
return 0;
}
/* Instruction's E uses stack reg as index. Check the reference. */
***************
-------
4-Aug-88 19:37:46-PDT,857;000000000000
Mail-From: KLH created at 4-Aug-88 19:35:23
Date: Thu, 4 Aug 88 19:35:15 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: KCC 607 - type check bugfix
To: info-kcc@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12419886694.31.KLH@SRI-NIC.ARPA>
Funny how they come all at once. This one fixes a bug where KCC complained
about "foo->a" when foo was declared as an array of structures. New binaries
as usual in SYS:CC.EXE and SYS:CCX.EXE, source change below:
;COMPARISON OF PS:<C.KCC.CC>CCSTMT.C.339 AND PS:<C.KCC.CC>CCSTMT.C.340
**** FILE PS:<C.KCC.CC>CCSTMT.C.339, 20-293 (55397)
/* Check that type of preceding expr is correct */
**** FILE PS:<C.KCC.CC>CCSTMT.C.340, 20-293 (55397)
/* Check that type of preceding expr is correct */
n = convarrfn(n); /* Apply array/funct convs */
***************
-------
15-Aug-88 18:32:55-PDT,1321;000000000000
Received: from MACBETH.STANFORD.EDU by SRI-NIC.ARPA with TCP; Mon, 15 Aug 88 18:10:30 PDT
Date: Mon 15 Aug 88 17:35:20-PDT
From: Stuart Nelson <S.SNELSON@MACBETH.STANFORD.EDU>
Subject: Extended addressing in kcc
To: info-kcc@SRI-NIC.ARPA
Message-ID: <12422748447.23.S.SNELSON@MACBETH.STANFORD.EDU>
An area in kcc where we would like to see some improvement is its
treatment of extended addressing. As the documentation states, kcc
can compile programs to run in extended (multi-section) memory. The
catch, however, is that all your code and variables (except auto
variables, which go on the stack) must fit in one section. For
large named arrays, structures, etc. we find this crippling. (This
problem arose in our case because we need to refer in C routines to
named COMMON blocks put in extended memory by TOPS-20 Fortran, and
there is no way to do this C as kcc stands. Comparisons are
invidious, but Fortran has options to load code and data directly
into extended memory.)
A related shortcoming that does not bother us as much is the
inability to call functions in another section. Our code fits in
one section, but code + variables does not.
Are there any other kcc users out there to whom either of these
problems is significant?
--Peter R. Samson
Systems Concepts
-------
26-Oct-89 14:05:05-PDT,1997;000000000000
Mail-From: KLH created at 26-Oct-89 14:00:38
Date: Thu, 26 Oct 89 13:56:01 PDT
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: ANSI KCC coming soon
To: info-kcc@NIC.DDN.MIL
cc: klh@NIC.DDN.MIL
Message-ID: <12537265452.62.KLH@NIC.DDN.MIL>
I wanted to reassure people that ANSI KCC does exist and I'm still trying
to get it into shape for distribution. Here's the story thus far:
With support from CompuServe, I spent most of the summer upgrading KCC
to both run on TOPS-10 and conform to the latest version of ANSI C
(formally still a "proposed ANS" text). The resulting implementation
has been undergoing testing and refinement on both TOPS-10 and TOPS-20
for the last couple of months. I was hoping to freeze things for a
while and start putting together a clean distribution, but just last
week CompuServe began running KCC through the Plum Hall test suite, and
sure enough this has shaken out a number of minor bugs (total thus
far looks like KCC 9, PH 1). Currently I'm waiting to see if any more
turn up before starting on the distribution.
The directory structure for the new KCC is quite different. I have
split the library routines into several subdirectories, and the
building process puts all binaries into a single directory which can
be configured for a specific machine or system. This was necessary so
I could maintain versions for several independent configurations in parallel
without duplicating the sources for each one.
So, of course, the procedures that I relied on in the past for taking
snapshots or writing tapes no longer work and I need to revise them as
well. I do, however, have a single directory that could be FTP'd if any
Internet TOPS-20 sites are dying to do beta-testing with the binaries.
Note that $$CVER has been bumped so anything used with the new KCC must
be completely recompiled.
Sometime later I'll be sending more messages describing some of the new
features, where things are, etc...
--Ken
-------
8-Mar-90 15:36:11-PST,2790;000000000000
Mail-From: KLH created at 8-Mar-90 15:26:25
Date: Thu, 8 Mar 90 15:26:19 PST
From: Ken Harrenstien <KLH@NIC.DDN.MIL>
Subject: ANSI KCC: come and get it!
To: info-kcc@NIC.DDN.MIL
cc: klh@NIC.DDN.MIL
Message-ID: <12572157964.22.KLH@NIC.DDN.MIL>
After so long, it's hard to believe -- but the ANSI version of KCC
is finally ready for network distribution! Thanks to CompuServe for
time support, SRI for hardware support, and Systems Concepts for the
final nudge.
You will need a new directory tree; you should NOT try to simply
update your existing KCC directories. It is best to start by first
FTPing these files from NIC.DDN.MIL:
KCCDIST:OBTAIN.DOC
KCCDIST:INSTAL.DOC
KCCDIST:-FTP-.MIC
For convenience, I am enclosing the new portion of KCCDIST:NEWS.TXT here:
----------------------------------
03/06/90 KCC 653, LIBC 606: <2,,3> Sixth formal distribution snapshot
General:
There are MANY changes in this version. The biggest and most
important is that KCC now supports the proposed ANSI C standard (as of
the December 7, 1988 draft), and almost all of the visible changes
stem from this. In particular, many library routines have been added
or modified, and for this reason the library version number has
been bumped to ensure that previously compiled modules cannot be
loaded without warning messages.
The other major bit of news is that KCC has been ported to
TOPS-10, including most of the library routines. The need to support
multiple configurations from the same sources led to a reorganization
of the way KCC source files are stored and used. You will definitely
need to read <KCC-6.BUILD>BUILD.DOC to learn again how to recompile KCC.
KCC+LIBC details:
Far too many changes to list here. You will have to read the new
CC.DOC and LIBC.DOC files to get an idea of what is different. You
really should get a copy of some reference that describes ANSI C (H&S 2,
K&R 2, or the draft itself); without these references, some error messages
may leave you mystified. I did not seriously attempt to retain complete
compatibility with former versions of KCC, judging that ANSI compatibility
was more important in the long run. Thus, things that previously compiled
may now fail to compile under the new ANSI regime.
Acknowledgements:
This version would never have happened without the help of
CompuServe Inc. and SRI International. The bulk of my time spent on
ANSI and TOPS-10 was supported by CSI, while SRI provided its own
local computer facilities -- many megabytes and many many CPU hours on
SRI's own DEC-2065 and SUN 3/60. In particular, thanks to:
Benny Jones (CSI everything)
Frank Kuo (SRI NISC facilities)
Steve Milunovic (SRI ISO facilities)
Dave Prosser (knotty dpANS queries)
-------