Defining ." and "

[Stefan Reinauer]

Hi,..

I tried the following 2 definitions:

HEX
0 > : " 22 PARSE ; IMMEDIATE
 ok
0 > : ." 22 PARSE TYPE ; IMMEDIATE
 ok

Now I try

0 > ." test"
test ok
0 >

which works fine. So does

0 > " test" TYPE
test ok

The following fails as the string is overwritten:
0 > " test"
 ok
2 > TYPE
PEst ok

I could not find the reason by quickly looking into it. Any ideas?

Stefan

[Stefan Reinauer]

* Stefan Reinauer  [020607 16:11]:
> HEX
> 0 > : " 22 PARSE ; IMMEDIATE
>  ok
> 0 > : ." 22 PARSE TYPE ; IMMEDIATE
>  ok

I got a bit further - Tried something like

: ALLOT HERE+ ;
: " 22 PARSE HERE C@ 1+ ALLOT ;

HERE+ seems to do what ALLOT is supposed to do, is that right?
I looked into the code and it seems a bit unclear to me. HERE 
should be like : HERE DP @ ;
As HERE is a prim word, and DP is not visible from outside, I looked 
into the code and found:

code_HERE:
{
        (++dp)->a = interpreter->here;
        NEXT;
}

code_HERE_X2b:
{
        interpreter->here += (dp--)->n;
        NEXT;
}

Looks like "dp" what is called SP/TOS, whereas &(interpreter->here) is
DP. Is this right? We should comment this or rename to a more intuitive
name scheming...

Using HERE+ for ALLOT did not solve the problem overwriting the text.
Any ideas?

Stefan

[Segher Boessenkool]

> HERE+ seems to do what ALLOT is supposed to do, is that right?

ALLOT has some additional alignment restrictions;  HERE+ just
adjusts the dictionary pointer.
> I looked into the code and it seems a bit unclear to me. HERE
> should be like : HERE DP @ ;
> As HERE is a prim word, and DP is not visible from outside, I looked
> into the code and found:
>
> code_HERE:
> {
>         (++dp)->a = interpreter->here;
>         NEXT;
> }
>
> code_HERE_X2b:
> {
>         interpreter->here += (dp--)->n;
>         NEXT;
> }
>
> Looks like "dp" what is called SP/TOS, whereas &(interpreter->here) is
> DP. Is this right? We should comment this or rename to a more intuitive
> name scheming...

"dp" is the Data stack Pointer, "rp" is the Return stack Pointer, "here"
is the dictionary pointer.
> Using HERE+ for ALLOT did not solve the problem overwriting the text.
> Any ideas?

See my previous mail.

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> The following fails as the string is overwritten:
> 0 > " test"
>  ok
> 2 > TYPE
> PEst ok
>
> I could not find the reason by quickly looking into it. Any ideas?

PARSE just return a pointer + size pointing to the input buffer...

To implement S" (or C") in the interpreter, you need an infinite supply
of temporary buffers.  Not sure how to do this...

To implement it in the compiler, I'll just have to decide on the
representation of strings in the dictionary.  I want to use pstrings
for it; I'll need to find out whether restricting (constant) strings to
length max. 255 is allowed, though :)

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[John R. Hogerhuis]

> To implement S" (or C") in the interpreter, you need
> an infinite supply
> of temporary buffers.  Not sure how to do this...

Well, I always thought if I tried to create such a
string from the interpreter that it would just end up
allocated (relatively permanently) in the dictionary.

Otherwise, you're going to have to allocate them from
the heap.

One way or another they are never getting freed,
right?

-- John.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..

[Segher Boessenkool]

> > To implement S" (or C") in the interpreter, you need
> > an infinite supply
> > of temporary buffers.  Not sure how to do this...
>
> Well, I always thought if I tried to create such a
> string from the interpreter that it would just end up
> allocated (relatively permanently) in the dictionary.
>
> Otherwise, you're going to have to allocate them from
> the heap.
>
> One way or another they are never getting freed,
> right?

Three ways:

1) garbage collect.  ouch.
2) in dictionary or similar --> never freed
3) in "string buffers" -- either 1 or 2, but both problems
less severe.

I think I'll just not implement S" in interpreting state at all.

Segher

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..