A Win32Forth kernel that supports PROC and CALL from the kernel directly. 
Author Message
 A Win32Forth kernel that supports PROC and CALL from the kernel directly.

Alex McDonald
says

Here's my new kernel for testing. It is at:

http://www.*-*-*.com/

John Peters says: (in BIG blue letters)
CONGRATULATIONS, and Thanks

It's a kernel that supports PROC and CALL from the kernel directly.
Notes are included in the zip file. Simply replace the *.F files in
the installation you have, and run

WIN32FOR.EXE FLOAD META.F BYE then
FKERNEL.EXE FLOAD EXTEND.F BYE Now run WIN32FOR.EXE.
You should get the line
--- Experimental Kernel V1.9F 23Aug2002 --- Rebuild
WINED (WIN32FOR FLOAD WINED.F BYE).
More to come now I have a kernel that allows Windows calls.
---
Alex McDonald

JP asks: Can some one please emblish on what this means and what are
some of the benifits.  I am too inexperienced to know, but I know it
is good for the Forth Community.
jp



Sun, 13 Feb 2005 08:40:46 GMT  
 A Win32Forth kernel that supports PROC and CALL from the kernel directly.

Quote:
> Alex McDonald
> says

---snip---

Quote:
> JP asks: Can some one please emblish on what this means and what are
> some of the benifits.  I am too inexperienced to know, but I know it
> is good for the Forth Community.
> jp

(My original post was on www.topica.com/lists/win32forth/read. But now
it's been posted on clf, here's a response...)

That's the same question TJZ asked when I said I was going to do this
-- so the benefits are those I see as important but that I believe
will be important for others too.

1. Removal of the C wrapper. Much of the operating system
functionality in the kernel had to be provided by coding C in forth.c
and then writing XCALLs (of which there are over 70!) to gain access
to them. Some of them provide file access, some provide memory
managment (both essential in the kernel), others printing and
ancilliary functions; all have to be written in C. Now, with PROC and
CALL in the kernel, all the XCALLs can be removed. (Bob Smith's
additions to the kernel would not have had to be written in C, for
instance). There are other long term benefits in doing this; W32F uses
an unusual .IMG file and associated Windows calls for loading and
executing the kernel; removing the wrapper makes for a cleaner
executable, makes W32F DLLs possible, enables the writing of services
etc -- and lets my de{*filter*} work too! Currently, the de{*filter*} I'm
using can't "see" the kernel image properly - it sees it as data
rather than code & data.

2. Much earlier calls to Windows. The original winlib.f was quite far
down the extend.f list, so windows calls couldn't be made (or at
least, made easily) prior to it. The original winlib.f appeared here:

EXTEND.F:
    FLOAD SRC\version.f     \ load the VERSION# definition
    FLOAD SRC\primutil.f    \ primitive utilities
\   FLOAD SRC\xdebug.f      \ a slightly simpler de{*filter*} loadable
early
sys-FLOAD SRC\nforget.f
    FLOAD SRC\pointer.f
    FLOAD SRC\dbgsrc1.f     \ source level debugging support part one
sys-FLOAD SRC\dthread.f     \ display threads

sys-FLOAD SRC\order.f       \ vocabulary support
sys-FLOAD SRC\module.f      \ scoping support for modules
    FLOAD SRC\ctype.f       \ 'c' style character typing
sys-FLOAD SRC\interpif.f    \ interpretive conditionals
sys-FLOAD SRC\resforth.h    \ load the headerfile with a few constants
sys-FLOAD SRC\transit.f     \ minimal transient support
    FLOAD SRC\fcases.f      \ extended CASE structure
    FLOAD SRC\assert.f
    FLOAD SRC\primhash.f    \ primitive hash functions for OOP later
    FLOAD SRC\see.f
    FLOAD SRC\debug.f
    FLOAD SRC\build.f       \ experimental version of BUILD DO:
defining wordset
    FLOAD SRC\later.f
    FLOAD SRC\winlib.f      \ windows stuff <-- no windows calls prior
to this
... etc

but now calls can be made from anywhere, at any time. For example,
PRIMUTIL.F contains the following:

: conDC         ( -- dc )               \ get the console device
context
                38 xcall ;

                                        \ bring up the printer page
setup
: print-setup   ( window_handle -- PrintDC )
                39 xcall ;

: print-start   ( -- )                  \ start printing a new page &
doc
                40 xcall drop ;

There are hundreds of calls to XCALL in here, and I for one find them
difficult to understand. All these can be replaced with windows calls,
and the associated XCALLs and FORTH.C support can be removed from the
kernel.

3. It's fun...

(Additional note -- it doesn't do any more right now than the standard
kernel. Using a PROC/CALL enabled kernel is down the line.)

---
Alex McDonald



Sun, 13 Feb 2005 19:52:50 GMT  
 A Win32Forth kernel that supports PROC and CALL from the kernel directly.

Quote:
> JP asks: Can some one please emblish on what this means and what are
> some of the benifits.  I am too inexperienced to know, but I know it
> is good for the Forth Community.
> jp

That's the same question TJZ asked when I said I was going to do this --
so the benefits are one's I see as important but that I believe will be
important for others too.

1. Removal of the C wrapper. Much of the operating system functionality
in the kernel had to be provided by coding C in forth.c and then writing
XCALLs (of which there are over 70!) to gain access to them. Some of
them provide file access, some provide memory managment (both essential
in the kernel), others printing and ancilliary functions; all have to be
written in C. Now, with PROC and CALL in the kernel, all the XCALLs can
be removed. (Bob Smith's additions to the kernel would not have had to
be written in C, for instance). There are other long term benefits in
doing this; W32F uses an unusual .IMG file and associated Windows calls
for loading and executing the kernel; removing the wrapper makes for a
cleaner executable, makes W32F DLLs possible, enables the writing of
services etc -- and lets my de{*filter*} work too! Currently, the de{*filter*}
I'm using can't "see" the kernel image properly - it sees it as data
rather than code & data.

2. Much earlier calls to Windows. The original winlib.f was quite far
down the extend.f list, so windows calls couldn't be made (or at least,
made easily) prior to it. The original winlib.f appeared here:

EXTEND.F:
    FLOAD SRC\version.f     \ load the VERSION# definition
    FLOAD SRC\primutil.f    \ primitive utilities
\   FLOAD SRC\xdebug.f      \ a slightly simpler de{*filter*} loadable early
sys-FLOAD SRC\nforget.f
    FLOAD SRC\pointer.f
    FLOAD SRC\dbgsrc1.f     \ source level debugging support part one
sys-FLOAD SRC\dthread.f     \ display threads

sys-FLOAD SRC\order.f       \ vocabulary support
sys-FLOAD SRC\module.f      \ scoping support for modules
    FLOAD SRC\ctype.f       \ 'c' style character typing
sys-FLOAD SRC\interpif.f    \ interpretive conditionals
sys-FLOAD SRC\resforth.h    \ load the headerfile with a few constants
sys-FLOAD SRC\transit.f     \ minimal transient support
    FLOAD SRC\fcases.f      \ extended CASE structure
    FLOAD SRC\assert.f
    FLOAD SRC\primhash.f    \ primitive hash functions for OOP later
    FLOAD SRC\see.f
    FLOAD SRC\debug.f
    FLOAD SRC\build.f       \ experimental version of BUILD DO: defining
wordset
    FLOAD SRC\later.f
    FLOAD SRC\winlib.f      \ windows stuff <-- no windows calls prior
to this
.. etc

but now calls can be made from anywhere, at any time. For example,
PRIMUTIL.F contains the following:

: conDC         ( -- dc )               \ get the console device context
                38 xcall ;

                                        \ bring up the printer page
setup
: print-setup   ( window_handle -- PrintDC )
                39 xcall ;

: print-start   ( -- )                  \ start printing a new page &
doc
                40 xcall drop ;

There are hundreds of calls to XCALL in here, and I for one find them
difficult to understand. All these can be replaced with windows calls,
and the associated XCALLs and FORTH.C support can be removed from the
kernel.

3. It's fun...

---
Alex McDonald



Sun, 13 Feb 2005 22:53:36 GMT  
 A Win32Forth kernel that supports PROC and CALL from the kernel directly.
Alex McDonald
says:

Quote:
>>Here's my new kernel for testing. It's a kernel that supports PROC

and >>CALL from the kernel directly. <snip>

Quote:
> > What are some of the benifits?
> 1. Removal of the C wrapper. <snip>
> 2. Much earlier calls to Windows. <snip>
> 3. It's fun... <snip>

Here's my updated kernel for testing (now version 1.9G).

http://www.rivadpm.co.uk/source/experimental/wincall.v1.9G.zip

I've taken on board the Rainbow Sally's suggestions (quick and easy
ones
only so far!).

Notes: 29Aug2002 1.9G

   Suggestions from Rainbow Sally implemented:

   1. .PROCS <optional substr>

      Show only procs that contain the case insensitive string substr.
      Works like WORDS.

   2. Corrected WINLIBRARY to make DLL name uppercase.

   3. Default action on CALL during compile is to attempt to find the
entry
      point. If it is not found, generates an error and stops
compiling.
      To defer failure until run-time,

         TRUE TO IGNORE-MISSING-PROCS?

      This allows creating code for DLLs that may not be on your
machine.  

   4. Corrected problem with incorrect length calculated for
winproc-len.
      Corrected minor doc errors in this doc.

---
Alex McDonald



Tue, 15 Feb 2005 16:18:20 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Win32Forth: Kernel Image

2. GPIB driver supports Kernel 2.4

3. Kernel Calls, Best Design

4. help calling a win3.1 Kernel function

5. help: how to call fortran95 routine of Intel Math Kernel Library in CVF

6. Kernel::big_endian? and Kernel::little_endian?

7. visual works 3.1 image has segmentation fault on 2.4 kernel (red hat 8.0)

8. density estimation, kernel functions etc

9. Real Time OS Kernel in Smalltalk?

10. Smalltalk-80 compatible implementation of kernel classes

11. VWNC3.1 on linux kernel 2.2.14

12. Kernel does not understand "abtPackagerOpenInitialViews"

 

 
Powered by phpBB® Forum Software