Re: Machine Forth vs ANS : 20 bits vs 32 bits

[msimon@xxxxxxxxxx (M.Simon)]

This was on CLF.  The reply was written by Elizabeth Rather.

The important point is: not enough good application examples.

From someone selling FORTH.

Simon
====================================
On Wed, 17 Mar 1999 14:55:24 -0800, in comp.lang.forth you wrote:

>John Chris Wren wrote:
>> 
>> I'm curious about how you write portable code in Forth, especially for "odd"
>> sized machines.  In 'C' you declare a long, and it's *generally* accepted
>> that a long is 32 bits.  If it's a 16 bit machine, then typically 2 registers
>> are used to form up a 32 bit word, or 4 8-bit memory locations are used.
>> 
>> In 'C' code that's cross compiler portable, most folks use typedefs or
>> #defines and create their own data types such as INT32, INT16, INT8, UINT32,
>> etc, and based on the compiler selection set those to produce the required
>> type.
>> 
>> Not being a very good Forth programmer myself, how do you write code that's
>> cross-word-sized portable?  Is this handled during compilation or run-time?
>
>The important issue in Forth programming is how many items are on the stack
>at various times.  A stack item is a "cell", and an implementation has a
>specified cell size, typically 16-bits (on 8- and 16-bit processors) or 32-bits.
>An address is specified to be one cell (on 16-bit systems with extended
>memory, there are "extended addresses" whose form is implementation-defined;
>this is not addressed in ANS Forth), as is a single-precision number.
>The other two standardized units are "characters" and "address-units".  On
>most current implementations both are equivalent to a byte, although there
>are some implementations I know of with 16-bit chars and AU's.
>
>There are standard operators for the most common conversions (e.g., CELLS 
>to AUs) and address arithmentic (e.g., CELL+ increments an address by one cell).
>If you follow these conventions (e.g., avoid using literals to increment
>addresses) it's quite easy to port an application from a 16-bit cell
>environment to a 32-bit one; we've done quite a few, both in-house and for
>customers.  It would be harder to go the other way, since numbers that fit
>nicely in a 4-byte cell need to be re-examined going down, but most ports
>are actually upgrades, so that isn't much of an issue.  There's some potential
>waste if double-length numbers are used where they aren't needed, but that's
>a fairly easy second-pass improvement.
>
>> Which brings (yet) another question to mind:  When y'all (that's southern)
>> are talking about portable, is this run-time portable or compile-time
>> portable?  Are people using lots of conditional compilation for this?  Seems
>> to me that unless you specifically target the machine you're running on, you
>> *are* going to take a hit in performance.  This may be as little as using a
>> deferred word to pick a routine optimized for the wordsize of the machine, or
>> as much as testing everytime you go to perform an operation that cares about
>> word size.
>
>The implementation is normally highly optimized for its target.  The application
>shouldn't have to be, given a competant implementation.  Run-time portability
>is out of the question, since an object is normally executable code.  We don't
>see much conditional compilation used to deal with cell size issues.
>
>> If the stack is 16 bits on machine X, and 32 bits on machine Y, what mechanism
>> takes are of passing 2 words back on X and one on Y?
>
>Parameter passing is in terms of stack items.  An 8-bit char is passed as the
>low order byte in a single stack item.  A double number requires two stack
>items,
>with the high-order part on top.  Strings are normally passed by their
>addr/length parameters. You would normally pass the same number of items
>regardless
>of cell size.  That is, the stack diagram for + is ( n1 n2 -- n3 ) where
>n3=n1+n2
>on all systems.
>
>> And better yet, can anyone point me at a *well documented* program that uses
>> some of these mechanisms?
>
>As has been bemoaned many times on c.l.f, there isn't a lot of published Forth
>application code.  Most programs are proprietary to the company that wrote
>them.  The biggest body of published Forth is the Forth Scientific Library, 
>available on www.forth.org.  The quality of its code and documentation varies
>from excellent to abysmal, in my opinion; contributions are vetted for accuracy,
>but
>there are no style police.
>
>Also, many systems include some libraries and examples.  SwiftForth has a lot.
>Most (unfortunately not all) are pretty well documented.  We keep improving
>them...
>
>Cheers,
>Elizabeth
>
>-- 
>===============================================
>Elizabeth D. Rather  (US & Canada) 800-55-FORTH
>FORTH Inc.                      +1 310-372-8493
>111 N. Sepulveda Blvd.     Fax: +1 310-318-7130
>Manhattan Beach, CA 90266
>http://www.forth.com
>
>"Forth-based products and Services for real-time
>applications since 1973."
>===============================================

Simon - http://www.tefbbs.com/spacetime/index.html