commit b705d776f5315785fbdef0d74ff71f2bbd118078
parent 27cd33457fb1d44b5f087e83905c7a5e274caac2
Author: Virgil Dupras <hsoft@hardcoded.net>
Date: Mon, 12 Jun 2023 11:43:26 -0400
Straighten out the "dict link" situation
There were remants of the old "0 c," dict link appendage in the code and docs
were still refering to it, even though dict structure has changed.
Moreover, this "0 c," in the struct structure is a no-go under ARM.
Diffstat:
5 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/fs/comp/c/type.fs b/fs/comp/c/type.fs
@@ -149,7 +149,7 @@ struct[ CDecl
\ Typedefs are dictionary entries in the "typedefs" dicts, which contain a 4b
\ value representing the type it aliases.
-create typedefs 0 , 0 c, \ this is a dict link
+create typedefs 0 ,
: addTypedef ( cdecl -- ) typedefs over CDecl name entry , ;
: findTypedef ( name -- type-or-0 ) typedefs find dup if @ then ;
diff --git a/fs/doc/arch.txt b/fs/doc/arch.txt
@@ -66,8 +66,8 @@ all share the same terminology.
## Dictionary links
Dictionary links, such as the "sysdict" variable, are not only linked lists, but
-also "noop" entries, that is, they have a 0 "len" field following the "next"
-field.
+also "noop" entries, that is, they don't match anything, but they're still a
+link in the chain.
This peculiarity opens interesting possibilities as it allows an entry to use it
as an "indirect" link.
@@ -80,11 +80,14 @@ to the system dictionary will not be present in the fork.
If, instead, you link your new forked entry to "sysdict" (without the @
dereferencing), then your "fork" becomes fluid: entries added to the system
-dictionary will also be part of the "fork" (but "under" it). However, if the
-byte following the "next" link has an undefined value, it's possible (although
-very unlikely), that this "fake" entry matches a real "find" operation. This is
-why we make sure that dictionary links such as the "sysdict" variable are always
-followed by a 0 len byte.
+dictionary will also be part of the "fork" (but "under" it).
+
+Note that at the moment, for all non-sysdict "dict links", we rely on luck to
+assume that the dict link won't match anything. That is: we simply have a 4b
+link field, which makes the value of the "length" field undefined. It's a bit
+wobbly at the moment, we might want to straighten it out at some point. On the
+other hand, in the regular "create mydictlink 0 ," situation, then length field
+ends up being metadata's MSB, which will very often be 0.
## Cross-compilation
diff --git a/fs/lib/context.fs b/fs/lib/context.fs
@@ -4,7 +4,7 @@ struct[ Ctx
]struct
0 value _current \ currently active context, 0=system
-create _system 0 , 0 c, \ this is a dict link
+create _system 0 ,
0 value _floaded
: system ( -- )
0 to@! _current ?dup if ( ctx )
diff --git a/fs/lib/struct.fs b/fs/lib/struct.fs
@@ -2,7 +2,6 @@
struct[ Struct
sfield dict
- 1 sallot \ 1b that is always zero after dict link. See doc/arch
sfield size
sfield lastfield \ pointer to field *word*
]struct
diff --git a/fs/xcomp/bootlo.fs b/fs/xcomp/bootlo.fs
@@ -300,10 +300,10 @@ code move ( src dst u -- )
0 value _bkp \ backup of sysdict to restore at ]struct
0 value _cur \ current struct entry
0 value _curroot \ root entry of the current struct hierarchy
-: structsz' ( struct -- a ) does' 5 + ;
+: structsz' ( struct -- a ) does' CELLSZ + ;
: structsz ( struct -- sz ) structsz' @ ;
: structdict' does' ;
-: structlastfield' structsz' 4 + ;
+: structlastfield' structsz' CELLSZ + ;
: _structfind ( 'struct "name" -- 'word )
@ ( 'dict ) word swap ( str 'dict ) find ( 'word )
?dup not if curword stype abort" not in namespace!" then ;
@@ -317,7 +317,7 @@ code move ( src dst u -- )
structdict' @ sysdict ! ;
: struct[
- doer immediate 0 , 0 c,
+ doer immediate 0 ,
_extends dup if structsz' CELLSZ 2 * move, else ( 0 ) , 0 , then
sysdict @ dup to _cur to _bkp
_extends ?dup if
