Re: CMOVE wrong?
- From: "J Thomas" <jethomas5@xxxxxxxxx>
- Date: 2 Mar 2007 20:37:20 -0800
On Mar 2, 9:36 pm, Elizabeth D Rather <erather...@xxxxxxxxx> 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 isNote the idea that the main memory moving word should be MOVE
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.
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
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
The words I see that use address units are:
ALLOT MOVE ERASE UNUSED
ALIGN ALIGNED CELLS CHARS
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:
: ALLOT CHARS ALLOT ;
: MOVE CHARS MOVE ;
: ERASE CHARS ERASE ;
: UNUSED CHARS UNUSED ;
: ALLOCATE CHARS ALLOCATE ;
: RESIZE CHARS RESIZE ;
: DUMP CHARS DUMP ;
: CHARS ; IMMEDIATE
and all your standard programs will work just as before, except that
standard programs that depend on address units being characters will
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?