home .. forth .. misc mail list archive ..

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


On Thu, Mar 18, 1999 at 09:09:05AM +0000, M.Simon wrote:
> This was on CLF.  The reply was written by Elizabeth Rather.
> The important point is: not enough good application examples.

I see another important point:

>> If you follow these conventions [...]
>> 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.

When trying to interoperate with (mainstream) 32-bit C applications,
20-bit isn't an upgrade path, but a downgrade path. Certainly,
going 40-bit double-precision systematically is possible,
but it is quite a waste. Also, many applications rely on the size being
*only* 32-bit (e.g. those that do multiprecision arithmetic as in RSA),
or on sizeof(int) == sizeof(void*),
so there will be quite a lot of gratuitous conversion problems,
not to talk about storing or coding/decoding standard 8-bit-wide
data streams into memory-starved 20-bit computers.
Finally, large RAM is becoming cheap and standardizing as chips providing
addressable in multiple of 8-bit.
20-bit data and address busses are just inadequate for those.

20-bit might (or not, *I* can't judge) be a good idea for autistic
embedded appliances, but are definitely a bad idea when
(hardware/software) interoperation is meant.
They are part of the problem set, not of the solution set,
all the more when using low-level languages like FORTH and C
instead of high-level languages like LISP or ML.
I think that MuP21's 20-bit size can be justified in a proof-of-concept chip;
they are just a gratuitous problem against success in a real product.

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
As long as software is not free, we'll have hardware compatibility,
hence bad, expensive, hardware that has decades-long obsolete design