On Apr 10, 8:53 pm, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> wrote:
> "m_l_g3" <m_l...@[EMAIL PROTECTED]
> schrieb im
Newsbeitragnews:6cd0431b-5ff2-45e6-b4cd-9d48acd679cc@[EMAIL PROTECTED]
>
>
>
> > On Apr 10, 9:54 am, "Stephan Becher" <stephan.remove-this.bec...@[EMAIL PROTECTED]
> > online.de> wrote:
> >> "m_l_g3" <m_l...@[EMAIL PROTECTED]
> schrieb im
> >>
Newsbeitragnews:b6409894-74ed-4089-a21a-3451cd458581@[EMAIL PROTECTED]
>
>
> > One more nice feature of the StrongForth is that it can cope with
> > return address manipulations.
>
> I don't think I understand what you mean by that. StrongForth does not
> encourage return stack manipulations. The examples you provide below are
all
> implemented as code definitions. Since StrongForth does not have
separate
> data type heaps for the return stack, it cannot determine the data type
of
> an item on the return stack. R@[EMAIL PROTECTED]
is actually implemented as a local that
is
> created by >R and removed by R>, because locals can have data types.
>
I know that R@[EMAIL PROTECTED]
currently is a local. I mean that StrongForth has a
potential to allow return address manipulations.
This, of course, will require tracking the data types on the return
stack, and, in the best case, type-checking the compiled code like
: lit ( r: ra -> single -- ) ( -- single )
r@[EMAIL PROTECTED]
@[EMAIL PROTECTED]
r> 1+ >r ;
: literal, ( single -- ) compile lit , ;
>
>
> > : (call) r> dup ref+ >r ref@[EMAIL PROTECTED]
>r ;
> > ( interpretation-stack: ra -> ref -- ra ra )
> > : (call) r> dup 1+ >r @[EMAIL PROTECTED]
>r ;
>
> > where interpretation stack is the return stack + ip (instruction
> > pointer, the register that changes each time a primitive is executed).
> > The rule of thumb is that when you call a colon definition, the
> > interpretation stack state becomes the return stack state; when a
> > colon definition is exited, the return stack state becomes the
> > interpretation stack state.
>
> > : lit ( interpretatins-stack: ra -> single -- ra ) ( -- single )
> > r@[EMAIL PROTECTED]
@[EMAIL PROTECTED]
r> 1+ >r ;
>
> > where 1+ adds the size of a single.
>
> > By the way, I would leave 1+ for arithmetic and have size+ for ptr ->
> > something..
> > 1+ for "one-plus", where "one" means "of that type" is a pun, but I
> > would not like to have it built-in into language.
>
> Address arithmetic in StrongForth involves 1+, 1-, +, -, +! (LOOP) and
> (+LOOP). I took over this feature from C because I like it very much. 1+
> means "next", no matter whether you deal with integers, character
addresses,
> cell addresses or double cell addresses. For a Forth programmer this
might
> look strange, but for a C programmer I'm sure it is quite natural.
>
> > By the way, what does 1+ do for a string?
>
> StrongForth does not have a data type for counted strings. In fact,
there
> are no words that directly operate with counted strings. Strings are
always
> represented in the address-and-count format, which has the data type
> representation CDATA -> CHARACTER UNSIGNED.
>
I meant not counter strings, but the (addr, len) pair. I see, it is
just a pair of values, not a data type.
> > : slit ( interpretatins-stack: ra -> string -- ra ) ( -- string )
> > r@[EMAIL PROTECTED]
@[EMAIL PROTECTED]
r> size+ ALIGNED >r ;
>
> > Note: ra points to run-time tokens; ra -> something points to
> > something followed by run-time tokens.
|
