$find

[Stefan Reinauer]

Hi,..

I just noticed some weirdness with $find

when I do
0 > s" constant" $find   ok
I get
3 > .s  120019b88 0 -1  ok

The definition from IEEE 1275-1994 is:
   $find  ( name-str name-len -- xt true | name-str name-len false )

Our definition seems to be wrong:
col($FIND LAST @ >R 2DUP R@ COMP-WORD ?BRANCH(9) 2DROP R> DUP 
    >XCODE SWAP CELL+ C@ TRUE EXIT R> @ ?DUP 0= ?BRANCH(-21) 2DROP FALSE)

what exactly does "SWAP CELL+ C@" do? should this not just be a NIP ?

according to this we would have to change COMPILE-WORD, INTERPRET-WORD,
', POSTPONE and FIND, some of which do the NIP afterwords themselfes, as
far as i can see.

Any comments?

Stefan

[Segher Boessenkool]

Stefan Reinauer wrote:
> Hi,..
>
> I just noticed some weirdness with $find
> Any comments?

Hahahaha!

You're right.

There's no $FIND listed in 7.3; that's why I thought I could change its semantics,
but actually it _is_ listed in 5.3 (device interface), so let's not
confuse things
by mixing up names :)

The $FIND I did returns the dictionary flags for the word found, btw;
that's handy
for things like INTERPRET etc.

I'll just name it (FIND) instead, and put a $FIND shim over it.

Thanks for catching,

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]

> Ah.. it fetches the word's flags, stupid me. This is not correct
> according to the standard, though we do need this flag.
>
> I have two things in mind:
> the word SEE
> the fcode evaluator
>
> for the first one we need to be able to get to a word's header when we
> have the execution token (xt). This seems impossible at the moment as
> we have a variable header length

Two easy solutions spring to mind:

1) have the flag byte be the lasy byte in the header (it's the first
   bybte right now);
2) have the flag byte have the high bit set always (so you can find it
   easily).

I think I'll go with 1).

BTW, nothing requires SEE to accurately show the flags of a word ;)
> for the second we need to know at least whether the word is compile-only
> or immediate, given only the xt. Currently my implementation of the

There's no need for COMPILE-ONLY wrt FCode; the FCode loader can assume
all FCode is legal FCode, the burden of checking is on the tokenizer.

More later,

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

[Stefan Reinauer]

* Stefan Reinauer  [020625 13:00]:
> 0 > s" constant" $find   ok
> 3 > .s  120019b88 0 -1  ok
> Our definition seems to be wrong:
> col($FIND LAST @ >R 2DUP R@ COMP-WORD ?BRANCH(9) 2DROP R> DUP 
>     >XCODE SWAP CELL+ C@ TRUE EXIT R> @ ?DUP 0= ?BRANCH(-21) 2DROP FALSE)
>
> what exactly does "SWAP CELL+ C@" do? should this not just be a NIP ?

Ah.. it fetches the word's flags, stupid me. This is not correct
according to the standard, though we do need this flag.

I have two things in mind:

* the word SEE
* the fcode evaluator

for the first one we need to be able to get to a word's header when we
have the execution token (xt). This seems impossible at the moment as
we have a variable header length

for the second we need to know at least whether the word is compile-only
or immediate, given only the xt. Currently my implementation of the
evaluator keeps a lookup table containing of xts for every word
available in fcode, using the fcode# as an index in this table. 
This is created via
' end0 ,
[..]

I wrote a little function for this problem, but it runs in O(N), linear
to the number of dictionary entries:

: xt>hdr ( xt -- addr-a )
  last @
  begin
    2dup >xcode = if
      nip exit
    then
    @ dup 0= until
  ;

This looks suboptimal, but I'm going to use it until something better
comes up.

Anny comments?

Stefan

[Stefan Reinauer]

* Segher Boessenkool  [020627 01:48]:
> > for the first one we need to be able to get to a word's header when we
> > have the execution token (xt). This seems impossible at the moment as
> > we have a variable header length
>
> Two easy solutions spring to mind:
> have the flag byte be the lasy byte in the header (it's the first
> bybte right now);
> have the flag byte have the high bit set always (so you can find it
> easily).
>
> I think I'll go with 1).
>
> BTW, nothing requires SEE to accurately show the flags of a word ;)

SEE still needs the word's name, which is ugly to get when you have
the XT only. Even though we don't really need a fast SEE. With the word
I posted we have O(N) instead of O(1), but this is acceptable taking
into regard that SEE is only for debugging anyways and we have the
sources without SEE ;)
> There's no need for COMPILE-ONLY wrt FCode; the FCode loader can assume
> all FCode is legal FCode, the burden of checking is on the tokenizer.

b(;) is a COMPILE-ONLY/IMMEDIATE word. The evaluator gets B(;)'s FCode#
and fetches it's XT. But it of course needs to find out that this word
must not be compiled but executed, when in compile mode.

Stefan

[Stefan Reinauer]

* Segher Boessenkool  [020627 01:47]:
> There's no $FIND listed in 7.3; that's why I thought I could change its semantics,
> but actually it _is_ listed in 5.3 (device interface), so let's not
> confuse things
> by mixing up names :)

good.
> The $FIND I did returns the dictionary flags for the word found, btw;
> that's handy
> for things like INTERPRET etc.

Yes, indeed. I fell over this when I started implementing the Evaluator
in Forth. In my case it's not of such a big help though because I need
to find the flags (and for debugging currently the name's word, too)
There I need to find that information from a given xt. Mapping fcode# to
words names is not an option as those are variable length and would slow
down things even more. Putting the flag as the last byte in the header
would help this, though.

Best regards,
  Stefan Reinauer

[Segher Boessenkool]

> SEE still needs the word's name, which is ugly to get when you have
> the XT only.

SEE ( "name< >" -- )
$SEE ( name name-len -- )
(SEE) ( xt -- )

SEE and $SEE -- I think it's quite easy to get the word's name here ;)

(SEE) can't in general find the name.
> Even though we don't really need a fast SEE. With the word
> I posted we have O(N) instead of O(1), but this is acceptable taking
> into regard that SEE is only for debugging anyways and we have the
> sources without SEE ;)

Also true.
> > There's no need for COMPILE-ONLY wrt FCode; the FCode loader can assume
> > all FCode is legal FCode, the burden of checking is on the tokenizer.
>
> b(;) is a COMPILE-ONLY/IMMEDIATE word. The evaluator gets B(;)'s FCode#
> and fetches it's XT. But it of course needs to find out that this word
> must not be compiled but executed, when in compile mode.

FWIW, I'm getting rid of COMPILE-ONLY altogether; and there'll be a separate
FCode-immediate (and probably not in the word's flags, but in the fcode table).

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

[Stefan Reinauer]

* Segher Boessenkool  [020628 15:08]:
> > SEE still needs the word's name, which is ugly to get when you have
> > the XT only.
>
> SEE ( "name< >" -- )
> $SEE ( name name-len -- )
> (SEE) ( xt -- )
>
> SEE and $SEE -- I think it's quite easy to get the word's name here ;)
>
> (SEE) can't in general find the name.

I am not talking about the word you want to see, but the words that are
compiled into this word's CFA. There you only have a pointer to another
CFA, but NOT to the word's header.
> FWIW, I'm getting rid of COMPILE-ONLY altogether; and there'll be a separate
> FCode-immediate (and probably not in the word's flags, but in the fcode table).

I agree, COMPILE-ONLY is somewhat duplicate with IMMEDIATE anyways as it
is nothing but an immediate word with no interpretion functionality.
But why add yet another flag for FCode? What should that be good for?

Stefan

[Segher Boessenkool]

Stefan Reinauer wrote:
> Segher Boessenkool  [020628 15:08]:
> > > SEE still needs the word's name, which is ugly to get when you have
> > > the XT only.
> >
> > SEE ( "name< >" -- )
> > $SEE ( name name-len -- )
> > (SEE) ( xt -- )
> >
> > SEE and $SEE -- I think it's quite easy to get the word's name here ;)
> >
> > (SEE) can't in general find the name.
>
> I am not talking about the word you want to see, but the words that are
> compiled into this word's CFA. There you only have a pointer to another
> CFA, but NOT to the word's header.

Ah okie.  True.  Will fix.
> > FWIW, I'm getting rid of COMPILE-ONLY altogether; and there'll be a separate
> > FCode-immediate (and probably not in the word's flags, but in the fcode table).
>
> I agree, COMPILE-ONLY is somewhat duplicate with IMMEDIATE anyways as it
> is nothing but an immediate word with no interpretion functionality.
> But why add yet another flag for FCode? What should that be good for?

COMPILE-ONLY is separate from IMMEDIATE; there's also (at least one)
COMPILE-ONLY word that isn't IMMEDIATE.  COMPILE-ONLY just means that
the interpreter will complain if you try to use the word while STATE
is OFF .

I think we'll be able to cope without an FCODE-IMMEDIATE flag as well; I
think all FCode's with special compilation semantics are separate from
normal Forth words anyway, so IMMEDIATE will do fine.

Anyway, I might give in and put the FCode in the words' headers.  We'll see...

Cheers,

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