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.