[ih] NCP and TCP implementations

Bernie Cosell bernie at fantasyfarm.com
Mon Mar 16 15:49:10 PDT 2020


On 16 Mar 2020 at 17:48, vinton cerf via Internet-hist wrote:

> On Mon, Mar 16, 2020 at 5:14 PM Andrew G. Malis via Internet-history <
> internet-history at elists.isoc.org> wrote:

> > I also assume that the C/70 microcode implemented some sort of
> intermediate
> > assembly with built in support for C constructs like procedure calls
> and
> > data structures, but I don't know for sure.

> that makes more sense than running native "C" code!!!


That's right.  The nature of the "instruction set" of the c/70 made it relatively easy 
to generate the "machine code" for C programs and it was assembled by a VERY 
simple assembler.  And, indeed, the microcode that Carl set up made it relatively 
easy to do most of the C constructs.

The tricky stuff came in the optimizations - in knowing that if you did a 
load-indexed-indirect and the index was small enough you could use the special 
instruction, but if it was larger than that you had to dosomething fancier.  Similar 
to what I mentioned with the subroutine call: zero or one args used one 
instruction and more than that used a different mechanism.  I don't remember 
exactly but I'm pretty sure I had the compiler optimize "switch" statements: it had 
three things it could do: if/then/else chain, dispatch table, or a hash table. and it 
picked the best one for the set of switch-keys.

As I recall, it also used a kind of hamming code for the actual instruction codes 
[is that term right, my ancient mind is foggy]: that is the thing had a variable size 
"opcode" field and so we used more bits for the "opcode" for some instructions 
and fewer bits for others.   for example, [NB I'm kinda making this up but the 
idea is right} : consider load immediate.  It takes three fields: opcode register 
constant.   Al figured out the optimal number of bits for the "constant" field, the 
register field was what it was, and the rest could be used for the opcode, so that 
pushed it somewhere down the opcode tree.   In the compiler, when it needed to 
do a "load immidiate" it *knew* whether the immediate part could fit in the 
instruction or whether it had to come from somewhere else.   My opinion [dunno 
about al or carl, or anyone else who has messed with the 'assembler' back end] is 
that it'd drive a programmer *nuts* to keep track of this operation allows nine-bit 
field, but this other allows a 15 bit field, etc.

  /B\


            Bernie Cosell
       bernie at fantasyfarm.com
-- Too many people; too few sheep --
   






More information about the Internet-history mailing list