hjm@cernvax.UUCP (Hubert Matthews) (09/19/88)
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
koopman@a.gp.cs.cmu.edu (Philip Koopman) (09/21/88)
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.
ir230@sdcc6.ucsd.EDU (john wavrik) (09/22/88)
Phil Koopman notes: > A year or two ago, Hans Niewenhuser (I *know* I spelled it incorrectly!!) > gave an argument at the Rochester Forth Conference that Forth has the > potential to be a strongly typed language. The argument for this is based > on the use of CREATE ... DOES> ... (or whatever your dialect calls it). > In most implementations, the DOES> re-points the code field to the DOES> ... > clause code. So, if you make each kind of variable with its own DOES> > field, then each kind of variable has a different CFA value. The CFA > value then contains the type information. A clever compiler (especially > an infix expression processor extension) can exploit this typing information > to do automatic type conversions. This observation is correct, it can be used and it works well. Obviously, however, the type checking only applies to named structures created by the defining word mechanism -- and it works to best advantage if the child words leave their address (cfa or pfa) on the stack. In this way the typing can be used in normal Forth (without a processor extension). This approach cannot be used, of course, to overload operation symbols (like +) which can be as well applied to integers as to named data. There are versions of Forth which do not operate in this way (for example the code field of a child word may point to a special "DOES" handler -- although in this case the pfa contains the address which can be used for typing. Unfortunately, the idea depends on an implementation feature of Forth. The Standards do not require DOES> to affect the cfa as indicated. From all indications future standards will be even less specific about how Forth should be implemented. Part of the power of Forth in the past has come from our ability to exploit common implementation features like this -- this may not be true in the future. --John J Wavrik Dept of Math C-012 jjwavrik@ucsd.edu Univ of Calif - San Diego La Jolla, CA 92093