Re: Machine Forth vs ANS : 20 bits vs 32 bits
- To: MISC
- Subject: Re: Machine Forth vs ANS : 20 bits vs 32 bits
- From: msimon@xxxxxxxxxx (M.Simon)
- Date: Thu, 18 Mar 1999 09:09:05 GMT
- In-Reply-To: <36F032DC.9970F653@forth.com>
- References: <36EE716C.51B9296@nospam.cis.uab.edu> <7cmcl0$o26$1@nnrp1.dejanews.com> <7cmk0m$v2s$1@nnrp1.dejanews.com> <36F032DC.9970F653@forth.com>
- Reply-To: msimon@xxxxxxxxxx
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