Re: [colorforth] Re: How is colorForth different from other Forths?

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Friday 12 December 2003 07:05 am, Robert Patten wrote:
>      Testing words in  Other Forths  leave a  true/false flag on the
> stack for " if  " and  other branching
> words   to remove and branch on false.
>       In ColorForth " if  " does not drop.    No other branching words
> are necessary.
>       In  Pentium ColorForth   previous words may set/reset,  0 and
> minus processor,   flags for " if  "or -if
> to branch on false.    The Pentium  colorForth " drop " does not 
> change flags allowing "<test> drop if" constructs.

I would phrase it this way.  It's a bit wordy though.  Not sure how I'd 
make it more succinct.

  Testing words in classical Forths leave a true/false flag on the stack 
for `if' and other branching words to use.  These testing words then 
consume the argument, and take steps to verify the boolean state of the 
operand before performing the decision operation proper.  While more 
mathematically correct, it results in slower code in all but the most 
advanced optimizing compilers due to redundant comparisons and multiple 
branches (one for the comparison operator, one for the ``if'' or 
``while'', et. al.).  Avoiding decisions is therefore more important in 
classical Forth than it is in other language environments.

  However, ColorForth's `if' exposes the underlying microprocessor's 
native test and control flow mechanisms directly, resulting in leaner, 
faster comparisons at the expense of purity.  This stems directly from 
its MachineForth heritage, where the primary philosophy of MachineForth 
is to ``exploit the built-in Forth CPU in every microprocessor.''  
Because of this, its implementation and use is largely processor 
specific.  In the case of the Intel x86-series of CPUs, certain words 
(such as arithmetic operations) modify the CPU's boolean flags, while 
other words (such as stack permutation words like DROP) do not.  Thus, 
phrases such as ``<expression> drop if'' become possible.  In other 
environments, such as the 6809 or 65816 microprocessors, flags are 
updated on almost every CPU instruction; therefore, ``drop if'' would 
likely not work on these processors.  Instead, either``<expr> if drop 
... then drop ...'' would have to be used, or `if'' must consume its 
argument.

  Just as the ``if'' word exposes the zero-flag of the underlying 
microprocessor, so too does ``-if'' expose the sign flag.  If it were 
necessary, it might be possible to expose the overflow flag via ``^if'' 
or some similar name.  Current ColorForth and MachineForth 
implementations do not have explicit overflow branch words, though they 
are quite easy to add.

  In the event where the state of the microprocessor's zero and sign 
flags are unknown, the word ``?'' is provided to enforce the proper 
settings of these flags, based on the current top of stack value.  As 
expected, ``?'' may or may not consume its argument, depending on the 
nature of the underlying hardware.

  For example, to convert a single hexadecimal character into its 
numerical equivalent, we might code it like so:

  ( Classical Forth )

  : hex# ( c-n) 48 - dup 9 > 7 and + ;

  ( 80x86 )

  : hex# ( c-n) 48 - dup 10 - drop -if exit then 7 + ;

  ( 65816/6502/6809 )

  : hex# ( c-n) 48 - dup 10 - -if drop exit then drop 7 + ;

Note that all of these will run with roughly equal performance, because 
the classical ``>'' operator includes its own branch operation in most 
cases.

> and digit  map).   Character icons are arranged in  a  Shannon-Fano 
> order in the icon table ,  to maximize the number of icons that can be
> stored in the 28 bits available in the name  object field of a word. 

Here's a contribution to consider; I'm not sure if you want to put it in 
or not.

Shannon-Fano encoding results in tight compression of text while also 
minimizing the decoding complexity of the characters.  Huffman encoding 
would yield tighter compression, but the software for it would be rather 
complex.  Shannon-Fano encoding permits the use of table-lookups for 
most of its core logic, while Huffman decoding requires bit-by-bit 
processing.

--
Samuel A. Falvo II


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com