[colorforth] IF How is colorForth different from other Forths?

["Robert Patten" <pattenre@xxxxxxxxxxx>]

Samuel,
My goal is to make simple correct comparisons between ANS Forth and
ColorForth
that are true and place the comparison and  responses in the colorForth
wiki.  Could you help me   separate what should be in the comparison and
what should be a response.
Robert

----- Original Message ----- 
From: "Samuel A. Falvo II" <kc5tja@xxxxxxxx>
To: <colorforth@xxxxxxxxxxxxxxxxxx>
Sent: Friday, December 12, 2003 8:33 PM
Subject: Re: [colorforth] Re: How is colorForth different from other Forths?


> 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


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