thomson@utcsrgv.UUCP (Brian Thomson) (06/09/83)
CAST YOUR VOTE TODAY!
You have the opportunity to influence the future of an NS16032 C compiler
developed here at the University of Toronto. We have not been able to
decide between National's favoured cxp calling sequence and the faster
jsr/bsr.
Our compiler and optimizer are now complete. Because of our vacillation,
we have parameterized them to generate either calling sequence. Now it
is time to install libraries and we have to bite the bullet.
We have made some measurements.
On a sample of 7 common utilities (pstat, ed, tar, ...) we find the
text size of programs using jsr is 5% greater than the optimizing 4.1bsd
VAX compiler produces. When we recompile using cxp, the cumulative
text size is 5% less than that on the VAX.
We then ran a speed test using the 'dc' calculator utility on
a 5MHz 16032 processor. One test calculated 10 ** 1000, and there
was no significant speed difference. A second test, involving no
multiplying but lots of loops and string executions, showed an 8%
speed advantage for jsr.
What do you think, and why? The issues are:
1) Speed vs. size, i.e. a technical decision
2) Compatibility. We understand that National-sponsored
C implementations are constrained to use cxp, while
MIT's effort uses jsr.
3) Whether 1) is more important than 2).
We would be particularly interested in responses from other implementors
especially if you can tell us the reasons for your choice.
Brian Thomson, utcsrgv!thomson
David Galloway, utcsrgv!drg
CSRG Univ. of Torontostevel@ima.UUCP (06/11/83)
#R:utcsrgv:-149900:ima:22400002:000:1343
ima!stevel Jun 10 11:54:00 1983
Subject: (notes) 16032 calling sequences
It is great to see some action in this group! I thought it had died.
Speed is not the only difference between the two. The ability to
dynamically link libraries into ones address space and therefore
be able to share single copies of libraries amoung different
processes becomes possible. This has many advantages/differences
to the way thing are done now.
>From a software engineering point of view when a bug is found in a
library it can be recompiled rather than recompiling all the
programs that use that library. This could have significant impact on
the ability to update programs.
On the disadvantage side there is aditional overhead involved in
doing dynamic linking/mapping of libraries. Also when a bug in a
library is fixed for one program then several others programs might
stop working.
If you are making a compiler for reasearch purposes it would be
good to do something different that would expand the possibilities
rather than more of the same. The straight forward conventional
compiler is well taken care of by the National/HCR/Translation
implimentations.
If you do a port of UNIX this could include kernel support for
dynamic linking of libraries.
Steve Ludlum decvax!yale-co!ima!stevel, ucbvax!cbosgd!ima!stevel,
{research|alice|rabbit|floyd|amd70}!ima!stevel,