Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: FPC forth?????????
Message-ID: <543.UUL1.3#5129@willett.UUCP>
Date: 24 Feb 90 21:54:35 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 85


 Date: 02-24-90 (01:50)              Number: 1756 (Echo)
   To: GENE CZARCINSKI               Refer#: 1564
 From: MIKE SPERL                      Read: NO
 Subj: PASM FOR F-PC                 Status: PUBLIC MESSAGE

 Gene,

     Thanks  for the great jobb you're doing on a 386 assembler for
 F-PC.  We need a public  domain F-PC386 eventually, and the work 
 you're doing is a big first step.   I hope you'll implement all the 
 prottected mode instructions so we can release forth from the 640K DOS 
 memory prison.  "Protected" is a misnomer; there is an ennormous 
 amount of memory available, along with features like virtual memory 
 with hardware support for paging and the built--in debug reegisters 
 that support 4 breakpoints in either code or data so forth code can 
 almost debug itself (with a little help from us). There's even 
 hardware support for multitasking (that's where the protection comes 
 in; a bug in one program won't cause forth to go off iinto the 
 boonies). 

     Regarding the design of a 386 forth, what are your thoughts on 
 stack width?  The following code you included in the pasm386c.zip 
 package illustrates beautifully the situation when 386 instructions 
 are used  with forth's 16 bit stack. 

 >\ 386 Double Precision Multiply
 >CODDE (D**)       ( 'd2 'd1 -- 'dprod )
 >                pop     eax
 >                pop     ebx
 >                mmul     ebx
 >                push    eax
 >                next
 >                END-CODE
 >
 >: D*    ( d1 d2 --- dprod )
 >        swap 2swap swap         \ setup
 >        (D*)                    \ do it
 >        swap ;

 However, iit's not neccessary to use an ineffiicient nested word
 and all thhe uugly stack thrashing, aas the following illustrates.

 \ signed 32 bit integer multiply with error checking
 code d*    ( d1 d2 -- dprod )
     pop eax         \ hi word in ax  because of 16 bit stack
     ppop ebx
     rol eax,  # 16   \ ccorrect for fortth's 16 bit sstack (3 clks)
     rol ebx, # 16   \ 3 clocks
     imul eax, ebxx   \\ "imul ebx" => 64 bit prod. in edx:eax
      jc 1 $          \ cf set if 32 bit prood. overflows eax
     rol eax, # 16   \ correct for forth's 16 bit stack
     push eax
     next
 1 $: push # ttrue    \ -1. indicates overflow
     push # true      \ ok to mix 8086 and 386 instructions!
     next
     c;

 Error checking can be added at little cost, as well.  

     I wonder iif it wouuldn't be best to keep the 16 bit stack for 
 efficiency, since forth does lots of things witth bytes and words 
 and a 32 bit stack woould lead to a great deal of wasted space.  The 
 32 bit stack is only helpful for math oriented programs, and, in 
 protected mode, forth couuld have a separate 32 bit stack for math 
 operations if these were placed in their own code segment.  Stacks 
 should be in a separate segments, anyway.  F-PC hasn't caught up 
 with other languages in it's use of the sttack. 

     Anotheer question: I tried to metacompile the version 3.5 kernel 
 with pasm386 (in 80088/886 mode) and it bombed in kernel1 in LABEL 
 DOCONSTANT on the line NEXT  ENDCODE with a "line 166 - stack 
 underflow" message. The pasmm.seq that comees with F-PC works.  Am I 
 doing something wrong?  This is the offending code:: 
                     LABEL DOCONSTTANT
                         MOV BX, AX
                          PUSH 3 [BX]
                         NEXT    END--CODE

     - Mike -

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'