On Sat, Jul 13, 2019 at 07:01:52PM +0200, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
Looking at the definition of this word in the detok output does not get me further as it just calls more of these words defined in the FCode:
8512: b(:) 8513: (unnamed-fcode) [0x86a] 8515: (unnamed-fcode) [0x864] 8517: b(") ( len=7 ) " map-out" 8526: (unnamed-fcode) [0x91f] 8528: (unnamed-fcode) [0x86c] 8530: (unnamed-fcode) [0x866] 8532: b(") ( len=7 ) " map-out" 8541: (unnamed-fcode) [0x91f] 8543: 0 8544: b(to) (unnamed-fcode) [0x86c] 8547: 0 8548: b(to) (unnamed-fcode) [0x86a] 8551: b(;)
: _... _86a _864 " map-out" _91f _86c _866 " map-out" _91f 0 TO _86c 0 TO _86a ;
8552: new-token 0x926
Here is the rest of it:
8555: b(:) 8556: my-address 8558: b(lit) 0x1000014 8563: my-space 8565: + 8566: (unnamed-fcode) [0x867] 8568: b(") ( len=6 ) " map-in" 8576: (unnamed-fcode) [0x91f] 8578: b(to) (unnamed-fcode) [0x86c] 8581: b(lit) 0x4 8586: my-space 8588: + 8589: dup 8590: b(") ( len=9 ) " config-b@" 8601: (unnamed-fcode) [0x91f] 8603: 1 8604: or 8605: swap 8606: b(") ( len=9 ) " config-b!" 8617: (unnamed-fcode) [0x91f] 8619: b(;)
: _926 my-address 01000014 + my-space + _867 " map-in" _91f TO _86c 4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
But I'm not sure. The config- words seem to be missing from OpenBIOS but SLOF does have these and it also fails on SLOF so maybe the exception is earlier in map-in?
The standard config-* words are methods of any specific PCI bus node. SLOF also has some in the global dictionaries, as convenience.
The 0x867 is just some variable and the " map-out" " map-in" is usually followed by $call-parent in other drivers I've seen in OpenBIOS and SLOF so I guess 0x91f should be that.
Yup.
Here's the detok output around there:
8033: new-token 0x91d 8036: b(:) 8037: const_0xb0 8039: (unnamed-fcode) [0x90a] 8041: b(;)
: _91d 00b0 _090a ;
8042: 0 8043: new-token 0x91e 8046: b(value)
0 VALUE _91e
8047: new-token 0x91f 8050: b(:) 8051: my-self 8053: 0<> 8054: b?branch 0x000b ( =dec 11 dest = 8066 ) 8057: my-self 8059: b(to) (unnamed-fcode) [0x869] 8062: bbranch 0x0009 ( dest = 8072 ) 8065: b(>resolve) 8066: (unnamed-fcode) [0x869] 8068: b(to) my-self 8071: b(>resolve) 8072: $call-parent 8074: b(;)
: _091f my-self 0<> IF my-self TO _869 ELSE _869 TO my-self THEN $call-parent ;
I.e.: if my-self is non-zero, just call $call-parent ; and if it is zero, set the previously used instance as current instance.
This is pretty curious.
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes before the : not after the ; in these listings.
Yes. new-token makes a word header without a name.
(But then what is 0x91e and if it's the value 0 then what about the :; block without new-token before that?)
I'm not sure which block you mean?
So is map-in map-out expected to work in OpenBIOS or is it known to be missing? Since these are also used by some OpenBIOS drivers and pci.c does have some code for these maybe it could work. SLOF has these words but some implementation just print a message and do drop2 so does not seem to be really implemented there but maybe it works I just can't read Forth.
SLOF runs in real mode, so its memory mapping functions are trivial.
Segher