Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: LANGUAGE OF ANS FORTH
Message-ID: <185.UUL1.3#5129@willett.UUCP>
Date: 5 Jan 90 16:04:58 GMT
Organization: Latest Link in ForthNet Chain
Lines: 35


 Date: 12-22-89 (17:32)              Number: 341
   To: JERRY SHIFRIN                 Refer#: 335
 From: IAN GREEN                       Read: NO
 Subj: LANGUAGE OF ANS FORTH         Status: PUBLIC MESSAGE

    Interesting. The reason for a formal definition is simple. This way 
 developers can design with a standard and be assured that code will run.
 As it is now I have difficulty learning the language because no two 
 Forths a totally compatible with one another.
    What I need is a clean clear formal standard in EBNF or other simular
 gramnmar description. Perhaps if I get time I will try to develope my 
 own formal definition and work from there.
    Perhaps a good place to start would be to define a Forth machine 
 standard that can execute Forth instructions. The question is what is 
 needed? Is this OK?

 TYPE ForthCPU = RECORD
        CC: CARDINAL;      (* condition code register *)
        IP: CARDINAL;      (* Instruction pointer *)
        RS: CARDINAL;      (* return stack *)
        DS: CARDINAL;      (* data stack *)
    END;

 My question is this. What other 'registers' do I need?

 After that what are the bare minimum words that the 'machine' has to 
 know? (execute)
 From there other words can be added in terms of the original 'machine' 
 instructions. This is the idea I think is best. Comments?

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'