Re: char and au size

Elizabeth D Rather <erather@xxxxxxxxx> writes:
Anton Ertl wrote:
Elizabeth D Rather <erather@xxxxxxxxx> writes:
Anton Ertl wrote:
However, many programs have an environmental dependency on 1 chars =
1, and all supported Forth-94 systems implement this, so it might be a
good idea to standardize this common practice.
...

I think that would be a terrible idea. The provision that Forth94 makes
for different-sized chars and AUs enables a considerable degree of
portability for high-level code on "exotic" platforms. FORTH, Inc.
supports several platforms for which chars and AU are different, and we
can run quite a lot of code on them without change.

Interesting. These would be counterexamples for my claim about
systems above, no?

Could you please tell me a few platforms where they are different, and
the respective sizes of chars and aus? Thanks in advance.

Hmm. The UT69R000 is a 16-bit cell-addressed system, but checking the
manual I see that we use a 16-bit CHAR, so it's still the same as an AU
(albeit not 8 bits). I'm pretty sure there have been some others, but
not in the current product lineup.

Ok, so my claim may be true after all.

Here's why I believe that it is true in general: For 1 chars > 1, an
au would have to be less than 8 bits (there's JaxForth, the
experimental attempt to use 16-bit chars with 8-bit aus, but that
seems to be a historical dead end), i.e. a 4-bit processor. My
impression is that people feel that Forth-94 is too heavy-weight for
such small machines, and they prefer to use something that is
extremely stripped-down (i.e., beyond reducing Forth-94 to the CORE
wordset).

So we won't see standard systems on such small machines, and all
standard systems will have 1 chars = 1.

As for 1 chars < 1 (what you might wish for on word-addressed 16-bit
or 32-bit machines), Forth-94 does not have provisions for that, and I
also don't see any common practice; my guess is that word-addressed
machines are not designed to do much string handling, so the need is
not that urgent even on these machines.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
.

Relevant Pages

  • aus and chars (was: CMOVE wrong?)
    ... (except on word-addressed machines). ... : ALLOT CHARS ALLOT; ... future standard systems (apart from that demonstration system by Jack ... based on) are also variable-width with byte granularity. ...
    (comp.lang.forth)
  • Re: aus and chars (was: CMOVE wrong?)
    ... Anton Ertl wrote: ... There is a weaker version of 1 CHARS = 1 that I thought of. ... No, MOVE went into Forth-94, and any systems that do not ... standard, so one level less. ...
    (comp.lang.forth)
  • Re: RfD: c-addr/len
    ... Then I wonder why you are asking us to get rid of CHARS ... encodings and MIME, when common practice is using MIME. ... Thus what we see for now, you design standard, you make another series ...
    (comp.lang.forth)
  • Re: What Is Wrong With Newswatcher?
    ... chars that demands the client to hard wrap the lines either ... don't recall brackets being a standard in the rfc to enclose wrapped ...    A multi-line data block is used in certain commands and responses. ...
    (comp.sys.mac.advocacy)
  • Re: C90 penetration
    ... and just specify that the "precision" ... A bit-field whose size is CHAR_BIT, can certainly be represented by a char; bit fields of a larger size clearly cannot be represented as a single char. ... Also, the standard requires that if a bit field with a width of 3 is followed by a bit field with a width of 4, then if there's enough room in the allocation unit, they must be allocated in adjacent bits within that allocation unit; that's pretty hard to do if you implement them as chars. ...
    (comp.lang.c)