Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Hardware type checking
Summary: unofficial viewpoint on hardware design
Message-ID: <3066@pt.cs.cmu.edu>
Date: 21 Sep 88 14:50:50 GMT
References: <829@cernvax.UUCP>
Sender: netnews@pt.cs.cmu.edu
Distribution: comp.lang.forth
Organization: Carnegie-Mellon University, CS/RI
Lines: 53

In article <829@cernvax.UUCP>, hjm@cernvax.UUCP (Hubert Matthews) writes:
> 
> Some LISP machines (all?) have hardware tags for run-time type-checking of
> operands.  Could such technology be applied to FORTH, so that a floating-point
> addition could detect in hardware, in parallel with the computation, whether
> its operands were of type floating?  Has any tried this?  Is it at all an
> interesting idea?  Could it be added to the Novix/Harris chips without 
> a complete rework?  How would a type mismatch be handled, given that real-time
> and control process programmers won't accept a core-dump as an error message?
> 	Hubert Matthews

Using tags for stack machines has a long history.  Many of the older
stack machines (non-Forth stack machines) have used tags, descriptors, etc.

Tags provide a memory size tradeoff.  Code size is theoretically smaller,
because you need fewer bits in an opcode (e.g. one "+" opcode works on all
types).  Data size is bigger, because each and every element of memory needs
tag bits.  This typically means 36-bit words on a 32-bit wide data path.
Forth programs tend to be very compact as it is, so my guess is that
tagging data will increase overall memory requirements.  Of course,
you have to make sure you have enough possible tag values for your
needs built into the tag system.  Tags don't work well for enforcing
strong types, because you typically need more than 16 types to do this.

One of the advantages of tags is that the programmer doesn't have
to keep track of data types.  To support mixed-type operations, the
hardware usually needs to do implicit type conversion.  The disadvantage
is that you loose control of automatic type conversion, which may be done
with wild abandon by the hardware.  Type conversion is very expensive.

Tags force dynamic decision-making at run-time.  Decision-making at run
time slows things down.  The way one of the RISC chips handles this (I think
it is the SOAR chip??) is to assume that all tagged quantities are
integer, then generate an interrupt for floating point or other values.
Interrupts are fast on stack machines, but not as fast as just doing
the operation you wanted in the first place.

My guess is that you won't see tags on any of the real-time control chips.
It costs additional hardware, and slows things down.  Also, tags are not
really in keeping with the Forth philosophy of the programmer being
responsible for what the machine is doing.  LISP machines are trying
to solve a different problem than real-time Forth machines, so tags
may make sense for LISP machines.

I've worked very closely with Harris on designing stack machine hardware,
so I have a good feel for these tradeoffs.  BUT, this is unofficial opinion,
not Harris' veiwpoint.


  Phil Koopman                koopman@maxwell.ece.cmu.edu   Arpanet
  5551 Beacon St.
  Pittsburgh, PA  15217    
PhD student at CMU and sometime consultant to Harris Semiconductor.