Re: CMOVE wrong?

On Mar 2, 9:36 pm, Elizabeth D Rather <erather...@xxxxxxxxx> wrote:
Ed wrote:
"Bruce McFarling" <agil...@xxxxxxxxxxxx> wrote in messagenews:1172672773.544960.248040@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 27, 11:50 pm, Elizabeth D Rather <erather...@xxxxxxxxx> wrote:
As I recall, Andreas' issue was with the argument order. The way it is
is mostly historical, but the concept was that internal to the MOVEing
word (note MOVE is the same) the count is usually handled first, and put
into a register or DO loop or something.
Note the idea that the main memory moving word should be MOVE
is not a call for any change in Forth-94, just a call for a
change in the way that some people use Forth-94 and describe
its use to others.

Getting people to adopt a new paradigm for moving strings will
require incentive. MOVE has the features but is awkward to use
because of the need to prepend CHARS. Convenience demands
a one-word solution. A suitable word for moving strings might
be called:

SMOVE ( from to count )

On most systems SMOVE would simply execute MOVE making
it cheap to implement. CMOVE would be retained for propagation
and CMOVE> become largely obsolete.

Is SMOVE anything other than CHARS MOVE? If so, what? If not, there
doesn't seem sufficient benefit, particularly since in 99.9% of cases
one can simply declare 1 AU = 1 CHAR and skip that step.

What good are raw address units? I remember asking somebody who was on
the standards committee in the early days about that, and he mumbled
something about somebody who'd been on the committee for a while who
had a system that was nibble-addressed, who insisteed address units
shouldn't be bytes. But after they catered to him he dropped out. If
you can address individual nibbles I don't see much you can do with
those addresses.

The words I see that use address units are:



A char is some number of address units and a cell is some number of
chars. So all that a standard program can do with odd address units is
it can ERASE them, and it can MOVE them. That's it.

There's no way to get a standard system to return an address that
isn't char-aligned except by something like 1+ or 17 + . If the system
gives you an address and you don't do anything to make it unaligned,
then it will be char-aligned and usually cell-aligned.

So it seems to me that if you happen to have a system where an address
unit is smaller than a char, you could do:



and all your standard programs will work just as before, except that
standard programs that depend on address units being characters will
also work.

Where you lose out is in special nonportable words that take advantage
of your system having an address unit of 1 bit or 1 nibble or
whatever. But you could work around that without a lot of trouble.

It looks to me like it should be very very easy for a system where an
address unit isn't a char to turn into a system where an address unit
is a char, if it needs to run code that depends on that.

So there is essentially no loss in portability at all, to leave CHARS
out of your standard code. Assuming that 1 CHARS 1 = will work on
almost all standard systems, and with minimal effort it will work on
all standard systems.

Am I wrong?


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 ...
  • 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. ...
  • 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. ...
  • 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. ...
  • 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, ...