Re: An Observation

On Mar 19, 6:21 pm, John Doty <j...@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
J Thomas wrote:

The original issue was whether LSE64 could be implemented portably in
Standard Forth. It cannot, because of the sloppiness of the standard.

Why can't it? Maybe the result can't be completely portable because it
might depend on behaviors that aren't completely portable. But even in
that case there might be a version that's largely portable, and other
versions that work for other Forths. I haven't seen anything yet that
I'm sure says it's impossible.

How many Standard Forths have just one cell size? It's allowed, but I
suspect very few go that route.

Not impossible. All I need is to redefine all the words that use chars
to use cell-size chars. I'd probably start with ACCEPT and READ-LINE
and have them put characters into cells with ! . Redefine CHARS and
CHAR+ . Redefine MOVE and FILL and ERASE . COUNT . FIND . I might have
a 32-byte buffer to pack with byte-size chars for FIND since otherwise
I'd be mucking around with things I can't do in standard Forth that
would be specific to particular systems.

It looks like a significant amount of work.

<# # #S #> HOLD SIGN ' ( ." : >NUMBER ABORT"ACCEPT C! C, C@ CHAR CHAR+
CHARS CONSTANT COUNT CREATE ENVIRONMENT? EVALUATE FILL FIND HOLD MOVE
POSTPONE S" SOURCE TYPE VARIABLE WORD ['] [CHAR]

Fix those and I'd have the core wordset handled. It might take fewer
because some of them are parsing words, for each dictionary word I
have to compact the strings since I can't rewrite them from scratch
short of setting up an entirely new dictionary structure. If I compact
a line at a time anyway, that's handled for those words.

So with COMPACT-STRING I get ' ( ." : ABORT" CHAR CONSTANT CREATE
EVALUATE POSTPONE S" VARIABLE WORD ['] [CHAR] all for free.

That leaves

<# # #S #> HOLD SIGN >NUMBER ACCEPT C! C, C@ CHAR+ CHARS COUNT
ENVIRONMENT? FILL FIND MOVE SOURCE TYPE

COMPACT-STRING also gives me a simple way to do >NUMBER ENVIRONMENT?
FIND TYPE . Just compact the string into a private buffer and do the
command against that buffer.

EXPAND-STRING can be used with #> to give <# # #S HOLD SIGN for free.
ACCEPT turns easy.

C! C, C@ CHAR+ CHARS COUNT FILL MOVE SOURCE are left. I seen no big
difficulty, it just looks like work.

It would be possible to redefine all the character-oriented words to
use cell-size characters, starting with any standard Forth. There
would be more work since the other wordsets would have things to
change too. I don't see any gotchas here, only some tedious coding.

.

Relevant Pages

  • 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)
  • Re: char and au size
    ... 1, and all supported Forth-94 systems implement this, so it might be a ... supports several platforms for which chars and AU are different, ... So we won't see standard systems on such small machines, ...
    (comp.lang.forth)
  • 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)