Use of ChiScript commands in printer drivers

In the following I present some words of caution using ChiScript commands in e.g. printer descriptor files ("printer drivers"), based on my personal experience. The effects of executing ChiScript code was deduced from a tedious study of the behavior of the printer driver code, by trial and error. The notes below are probably only understandable to those familiar with ChiScript (and maybe not even to them). No claim whatsoever is made concerning the actual correctness of the statements, but they may be of some help to users who start experimenting with ChiScript code.

  1. All ChiScript composite data structures (lists, atoms, strings and procedures) are represented by a pointer to a memory address. If a composite value is placed on the stack it is in fact only a single pointer. Nested structures are built up using pointers in random memory, not on the operand stack. The only values that represent themselves on the stack are "numbers" (characters, integers).
  2. The commands dup, set, def, setstr do not copy the values, but only the pointer to that value. Thus "array" list set assigns a pointer to the identifier array in the ChiScript dictionary (global scope for identifiers), pointing to list. Hence this list is shared! Changing array means that the original list is changed as well. Take into account all possible side effects that originate from this aliasing effect. If in doubt, use copy instead of dup: this yields a pointer to a fresh copy on the stack. Don't forget to xchg pop the original.
  3. Even the ChiScript code of, say, a printer driver is built up as a pointer structure as it is read in. When the code is executed at startup, all the identifiers present in the dictionary are replaced with their actual values (pointer or simple value). Unknown identifiers (e.g. at the time of reading not yet set or defined) are left in the structure as pointers to the atom name. This implies that primitive procedures may treat the atom name string as if it were the list it is supposed to point to. In such cases the identity of the field the pointer points to is not checked, and if it is an atom name, the dictionary is not consulted, as it should be. This faulty behaviour occurs for the standard procedure fontwidth. If the width table is just a name for some list, the name string is treated as if it were the width table itself. The fontmap procedure behaves correctly in this respect. A remedy for this flaw is to place the name of the width table behind the font width triple, and perform a 2 put operation. When the name is placed on the stack, the dictionary will be consulted, as it should.
  4. Even explicit constant lists in the ChiScript code are not to be trusted! As remarked earlier, the code itself is a pointer structure in memory, and a set command just assigns a pointer to the "constant" list in the code to some atom in the dictionary. If the atom is changed later, so is the code itself! This self-modifying code possibility is sometimes referred to as "Von Neuman's sin". If a constant list is to be changed, in addition to inspection only, use copy xchg pop set.
  5. If the name of an atom is to be used instead of the value it refers to, use double quotes before and after the name. For instance font names, if the name is to be substituted somewhere instead of the reference to the font itself. If the name appears in a list constant quotes are optional, because such lists are not really placed on the stack, only a pointer to it, and this implies that the list is not inspected, and names are not replaced by the values they refer to anyway.

Last updated May 30th, 2006.
Back to the version 4 package.
Back to the ChiWriter home page 
Back to Joop's home page in English
Terug naar Joop's home page in het Nederlands