Forth Core and Kernel Design 
Author Message
 Forth Core and Kernel Design

Category 20,  Topic 23
Message 3         Sat May 01, 1993
B.RODRIGUEZ2 [Brad]          at 10:58 EDT

Quote:
> I am seeking to start a thread on the design of the Forth Core ?

Ahem.  If I may be allowed to blow my own horn (toot, toot), I have just begun
a series of articles on this very topic in The Computer Journal.   Parts 1 and
2 have appeared in TCJ issues #59 and #60; Part 3 is planned to appear in
issue #62.  Contact
  The Computer Journal
  P.O. Box 535
  Lincoln, CA  95648-0535
  (916) 645-1670
  (800) 424-8825 credit card orders; may not work from Canada

A one year (six issues) subscription to Canada is US$32 (surface), US$34 (air
mail).  Back issues are $4 plus shipping of $1.25 (surface) or $1.75 (air),
each.

Quote:
> ...I would like to experiment with building a MetaAssembler.

You might also be interested in TCJ issues #52 and #54, where I described how
to build an assembler in Forth...including the higher level control
structures, and some comments on meta-assemblers.

Also, I wrote a three-part series on metacompilers in Forth Dimensions XIV:3,
XIV:4, and XIV:5.  Back issues are usually available for $20 per volume (six
issues), plus shipping.  Contact
  Forth Interest Group
  P.O. Box 2154
  Oakland, CA  94621
  (510) 89-FORTH

Last plug: the next meeting of Southern Ontario chapter of the Forth Interest
Group will probably be the first Saturday in June, at McMaster University in

for more information.

Brad Rodriguez          B.RODRIGUEZ2 on GEnie


 So many projects....so little time.

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).



Fri, 20 Oct 1995 01:21:48 GMT  
 Forth Core and Kernel Design

 Well, yes and no.....
    In standrad Forth, there is a Compile mode and a Run mode. Some
use a STATE variable to determine which is current, others do so by
Stack States. BOTH use the QUIT word, which is generally tied to
INTERPRET, ie, that word which "interprets" the line just handed the
input. (Whether from keyboard or file.)
   A reasonable defintion of Quit would be;
   EXPECT-LINE PARSE-A-WORD IF-FOUND-EXECUTE ELSE-ENTER COMPLIE
THEN-REPEAT-TIL-DONE
     This would be the Main() routine of any C program that took
control of the keyboard input, locating key words or functions and
performing the commands asked of it. (Though in today's philosophy,
it'd be the mouse that says (points) out the commands instead of
typing them.... same result, just different interface.)

--
via Fortress Gateway at uumind.mind.ORG



Sat, 21 Oct 1995 17:48:00 GMT  
 Forth Core and Kernel Design

 Oh dear!
   Can we talk? (ala Joan Rivers!)
   The whole concept of booting onto a machine has almost become a
science in itself, given what the hardware can and cannot do, and
which forth you intend to implement and what access you have to the
processor at the time. (I've done, and know of others that have only
had BASIC upon which to tie into the machine, a most agrivating
state of your affair! hehehehe)

--
via Fortress Gateway at uumind.mind.ORG



Sat, 21 Oct 1995 16:58:00 GMT  
 Forth Core and Kernel Design

        Forth Cores and Kernels Design
        ------------------------------ part 3

   I think the Virtual Machine that is Forth is an interesting puzzle.!.

   Why does Forth have just one type of Next Word?  I would have thought
there would be several?  If it was a CPU there would be need of more than
one type of addressing and what about the use of the source as an immediate
value of quick addition or subtraction??

   I see several problems with assuming only one type of next call!
The most troublesome is the test and branch which requires a fall through
or a branch to be taken, this opWord needs at least two positions to store
the address of the word and the address of the branch. Falling through
means skipping over the branch address, but since this does not happen
often it is a waste to have the next word always checking to see if a
branch has just been executed.  Of course the branch could correct the IP.

   What about building tables with a base, an offset, and an index.?
This too requires that two or three values be used to determine the address,
location, of the stored data. Again the compiled mode needs to be able to
place the information in sequence and the next word needs to be able to
use it correctly.

   I would think this does not make for speedy execution speeds.

   Another point there seems to be none or few methods to deal with
different sized data.  Byte= 8 bits, Word= 16 bits, Long= 32bits.
Bits and collections of bits as a nibble or byte or word ... ???

   If an Operating System needs to be delt with then most likely a
structure of some kind will need to be build to receive and send data.
Or what of interrupt handling (?) does this too not need to be apart of
the Virtual Machine?

   I think it interesting that to build and understand Forth one needs to
understand the problems of building a CPU and the microcode there in!
Many of the flag and status bits found in a CPU seem to be absent in Forth,
is this by design or just an oversite?

   Some one was wondering about stack manipulation? If you fix an array
with element zero at the last position item pushed on to the stack, then
the array elements remain fixed and usable until stack operations cause
them to be overwritten.  It would be one way to fiddle the elements of
the stack around with ease and have unlimited access to the stack.

   If anyone has a question on this subject, Please feel free to post in
this thread. I think the qiestion is of as much interest as the answer
that will hopefully follow.


--



Mon, 23 Oct 1995 18:17:49 GMT  
 Forth Core and Kernel Design

Quote:

>   Why does Forth have just one type of Next Word?  I would have thought
>there would be several?  If it was a CPU there would be need of more than
>one type of addressing and what about the use of the source as an immediate
>value of quick addition or subtraction??

>   I see several problems with assuming only one type of next call!
>The most troublesome is the test and branch which requires a fall through
>or a branch to be taken, this opWord needs at least two positions to store
>the address of the word and the address of the branch. Falling through
>means skipping over the branch address, but since this does not happen
>often it is a waste to have the next word always checking to see if a
>branch has just been executed.  Of course the branch could correct the IP.

>   What about building tables with a base, an offset, and an index.?
>This too requires that two or three values be used to determine the address,
>location, of the stored data. Again the compiled mode needs to be able to
>place the information in sequence and the next word needs to be able to
>use it correctly.

>   I would think this does not make for speedy execution speeds.

Forth is designed around a virtual machine, when you implement it on a
real CPU then you have to deal with questions like these.  The inner
details of indirect threaded, direct threaded, and subroutine threaded
implementations of Forth handle these things differently.  A Forth
implementation that compiles optimized machine code can handle NEXT in
any way you choose.  You can certainly have more than one way to do a
NEXT.  Similarly subroutine threaded Forths usually compile machine
specific CPU opcodes to handle branching most efficiently.  Addressing
modes are specific to hardware, there are dozens of different
implementations on the Intel 80x86 family alone.  Some use multi-segmented
models and others do not.  There is no restriction to the implementor
of the language with regard to machine specific details except those
that are detailed in the proposed ANSI standard.

Quote:

>   Another point there seems to be none or few methods to deal with
>different sized data.  Byte= 8 bits, Word= 16 bits, Long= 32bits.
>Bits and collections of bits as a nibble or byte or word ... ???

You might check the ANSI standard again here.  Words are not always
16 bits, or Longs 32 bits, this is CPU specific stuff again.

Quote:

>   If an Operating System needs to be delt with then most likely a
>structure of some kind will need to be build to receive and send data.
>Or what of interrupt handling (?) does this too not need to be apart of
>the Virtual Machine?

Interrupts are machine specific again.  Some Forth systems include code
to permit definitions of interrupt routines from Forth others do not.
Consider that some CPU do not support interrupts at all.  So this needs
to be implementation specific.

Quote:
>   I think it interesting that to build and understand Forth one needs to
>understand the problems of building a CPU and the microcode there in!
>Many of the flag and status bits found in a CPU seem to be absent in Forth,
>is this by design or just an oversite?

Understanding Forth exists on different levels.  You can understand Forth
as an application programmer without having built your own Forth.  Also
building a Forth system will require understanding the inner workings of
Forth more than an applications programmer, and it does require some
specific CPU knowledge, but it CERTAINLY DOESN'T require knowing how to
build a CPU.  (also note that microcode is not required to build a CPU)
FLAG and STATUS bits of a CPU are just that, not high level stuff, they
are machine specific.  So FLAG and STATUS bits to the CPU could be
implemented on some specific CPU and Forth, but it would not be portable
to a machine with a different implementation of these hardware features.

Quote:
>   Some one was wondering about stack manipulation? If you fix an array
>with element zero at the last position item pushed on to the stack, then
>the array elements remain fixed and usable until stack operations cause
>them to be overwritten.  It would be one way to fiddle the elements of
>the stack around with ease and have unlimited access to the stack.

Again this is CPU and implementation specific stuff, handle it they way
you want, but you may find this will be useless if you have a CPU with
stacks implemented on chip. But many implementations of Forth would
allow code to treat stack space as an array.  But in general it is good
practice to treat a stack as a stack.  Many implementations of Forth
on the 80x86 keep at least the TOP of stack in a register and keep the
rest of the stack in memory for better performance than keeping the
entire data stack in memory.

The proposed ANSI standard addresses the problems of machine specific
and implementation specific stuff, and to be ANSI compliant many of
these implementation ( Environmentally dependent ) details of a system
must be documented.

I hope this answers these questions about Forth.  

Jeff Fox



Tue, 24 Oct 1995 03:00:04 GMT  
 Forth Core and Kernel Design

Quote:

>   I think the Virtual Machine that is Forth is an interesting puzzle.!.

I agree.

Quote:
>   Why does Forth have just one type of Next Word?  I would have thought
>there would be several?  If it was a CPU there would be need of more than
>one type of addressing and what about the use of the source as an immediate
>value of quick addition or subtraction??

A CPU needs more than one type of addressing partialy because of the
need for more than one type of programming structure.  An individual
forth has a specific programming structure.  

Quote:
>   I see several problems with assuming only one type of next call!
>The most troublesome is the test and branch which requires a fall through
>or a branch to be taken, this opWord needs at least two positions to store
>the address of the word and the address of the branch. Falling through
>means skipping over the branch address, but since this does not happen
>often it is a waste to have the next word always checking to see if a
>branch has just been executed.  Of course the branch could correct the IP.

I don't see how next must check to see if a branch just occured.  The
Next generaly consistes of 2-4 instructions.  It is hard to call any of
these instructions a wast (unless you are using an indirect-threaded
interpreter and would prefer direct).

I (think I) understand how the IF THEN conditional construction is
used in forth.  This is my guess as to it's internal working (how I
would first attempt to impliment it).  IF would be an immediate word.
It would leave a pointer to (IF), the run-time if statment, it would
also leave an empty address-sized space on the dictionary.  THEN would
also be an immediate word.  It would search back to find the address of
(IF) and insert a pointer to the current dictionary top.  The job
of (IF) would be to test the stack, and to adjust the IP register,
either by incresing it by one (in order to skip the address left by
THEN)  or by loading it with the pointer left by THEN.  It wouldn't
too difficult to modify this system to include ELSE.  

Quote:
>   What about building tables with a base, an offset, and an index.?
>This too requires that two or three values be used to determine the address,
>location, of the stored data. Again the compiled mode needs to be able to
>place the information in sequence and the next word needs to be able to
>use it correctly.

Next is only used after words that are part of the Forth dictionary
structure.  The forth dictionary structure allows Next to presume many
things about where to find the next word.  Next must be
appended to the end of every word.  If you want to define a different
structure and call words from it, you can, but those words must have a
changed next appended to the end of every one of them.  With this
changed next the words can no longer be used from standard forth.

Quote:
>   I would think this does not make for speedy execution speeds.

The consistancy in the structure allows forth to do a fair range of
things rather quickly (provided the processor hasn't been optimsed to
much for compiled languages).  If you want to do something complex and
quickly it is acceptable (according the the autorities that affect me)
to create any structure you want.  You can then create forth words (in
assembly) to manipulate these structure.  This takes time, but less than
it does to write it in pure assembly (gross generalization and
opinionated).

Quote:
>   Another point there seems to be none or few methods to deal with
>different sized data.  Byte= 8 bits, Word= 16 bits, Long= 32bits.
>Bits and collections of bits as a nibble or byte or word ... ???

This is related to the fact that no major forth standard has addressed
this question.   Each forth that has needed to deal with this has
simply created it's own method (again, generaly speaking).  I think that
the ANSI proposal will try to change this, but I am not certain.

Quote:
>   If an Operating System needs to be delt with then most likely a
>structure of some kind will need to be build to receive and send data.

Yes, but this structure has always been considered OS-dependent and
therefore non-stadarizable.  I think that ANSI may be changing this to, but
I can't say for certain.

Quote:
>Or what of interrupt handling (?) does this too not need to be apart of
>the Virtual Machine?

There is no standard way of handling interupts in forth.  This is
because people who use forth also tend to prefer to have fast interupts.
Different forths use differenent methods of interupt handling.  In my
household this method is chosen to be appropriate to the processor.

Quote:
>   I think it interesting that to build and understand Forth one needs to
>understand the problems of building a CPU and the microcode there in!
>Many of the flag and status bits found in a CPU seem to be absent in Forth,
>is this by design or just an oversite?

Forth is not intended to imitate a processor.  The forth virtual machine
is the collection of registers that are required to have forth.  It does
make very clear what parts of a CPU are most important to run forth,
doesn't it?

The various flag and status bit change with the processosr.  Therefore,
forth tries not to deal with them directly.  If you want to address
them, it is easy to write primitives to do so.  Such words, however,
would not be includable in any standard forth.  Ussualy, however, they
are only used to impliment forth primitives.  For example, if I wanted a
64 bit by 64 bit multiply, I would write it as a primitive.  This is
because the easiest way to do this is very machine depedent anyway.
Such a definition would almost certainly use a status register or two.

Quote:
>   Some one was wondering about stack manipulation? If you fix an array
>with element zero at the last position item pushed on to the stack, then
>the array elements remain fixed and usable until stack operations cause
>them to be overwritten.  It would be one way to fiddle the elements of
>the stack around with ease and have unlimited access to the stack.

I'm sorry, but this paragraph confuses me to no end.  Could you try to
explain it a bit more?

I don't know if everything I have said is factualy correct.  If you want
to correct me, please do.  Opinions are my own, and they don't need
corrected (which isn't to say that I don't like  good argument).

--

Ben Galehouse              Doylestown, OH, 44230
(216) 658-3556          



Tue, 24 Oct 1995 04:08:22 GMT  
 Forth Core and Kernel Design

Quote:

>        Forth Cores and Kernels Design
>        ------------------------------ part 3

>   I think the Virtual Machine that is Forth is an interesting puzzle.!.

>   Why does Forth have just one type of Next Word?

Er, you mean the inner interpreter?  (Which is not what is usually called
a "word" in Forth; a "word" usually has a header, and can be called by
other words.)  Because it's simple and efficient.  Having several inner
interpreters would add a lot of complexity and reduce the performance of
the system.  And would add little real benefit to compensate.

However, it's worth noting that Forth, per se, does not specify the
mechanism of the innter interpreter.  And there is nothing to prevent
someone from designing a Forth system that uses multiple inner
interpreters.  There's also the case of subroutine threaded code, which
doesn't use *any* inner interpreter.

Quote:
>  I would have thought
>there would be several?  If it was a CPU there would be need of more than
>one type of addressing and what about the use of the source as an immediate
>value of quick addition or subtraction??

Addressing is typically done in the code, on the parameter stack.  The
inner interpreter doesn't need to do any fancy addressing.  This is
handled, when needed, by the compiled words themselves (more on this
below), which makes the system simpler, faster, and more efficient.
Exceptions are handled by the code that needs an exception, rather than
being built into the core of the system.  As for the "source", I guess
that you are referring to the value referred to as "HERE"?

Quote:
>   I see several problems with assuming only one type of next call!
>The most troublesome is the test and branch which requires a fall through
>or a branch to be taken, this opWord needs at least two positions to store
>the address of the word and the address of the branch. Falling through
>means skipping over the branch address, but since this does not happen
>often it is a waste to have the next word always checking to see if a
>branch has just been executed.  Of course the branch could correct the IP.

The last sentence reveals the solution to your question.  This is
*exactly* how it is done!  Thus leaving a small, simple, fast inner
interpreter.  The exception is handled by the code that needs the
exception, rather than trying to predict and build every possible
exception into the base system.  This is the same philosophy as is used
in the compiler:  words like IF and DO handle the complexity of building
branches.  The compiler itself has no idea how to do anything more than
look up words in the dictionary and either compile or interpret them.

Quote:
>   What about building tables with a base, an offset, and an index.?
>This too requires that two or three values be used to determine the address,
>location, of the stored data. Again the compiled mode needs to be able to
>place the information in sequence and the next word needs to be able to
>use it correctly.

I don't understand the question.  Building what sort of tables?  And to
what end?  Why does the inner interpreter have to have any knowledge of
your data structures?  Perhaps an example would help here.

Quote:
>   Another point there seems to be none or few methods to deal with
>different sized data.  Byte= 8 bits, Word= 16 bits, Long= 32bits.
>Bits and collections of bits as a nibble or byte or word ... ???

First of all, the sizes of the data-types is a machine dependency.  For
example, on a Sun or 68k or 386, a word (which is usually called a
"cell" in Forth parlance to distinguish it from "words" like IF and TYPE
and CREATE) is 32 bits, and a "long" (called a "double") is 64.

As for bit fields, these are a hassle in nearly any high-level language.
C has bit-elements of structures, but they are notoriously unreliable
if you expect the bits to be located at any particular position.  Other
languages are even worse in this regard.

Quote:
>   If an Operating System needs to be delt with then most likely a  
>structure of some kind will need to be build to receive and send data.

Yes, and Forth doesn't have any particular problems with this.  Did you
have a question here?

Quote:
>Or what of interrupt handling (?) does this too not need to be apart of
>the Virtual Machine?

A highly machine dependent issue.  I think it might be nice if Forth had
something like C's signal() word, but I'm not quite sure how it would
work.  There are substantial differences between an interpreted language
like Forth and a purely compiled language like C.

Quote:
>   I think it interesting that to build and understand Forth one needs to
>understand the problems of building a CPU and the microcode there in!  

One does?  News to me!  :-)  I don't think that this is at *all* a
requirement!  In fact, I disagree vehemently.  I have taught several
people about Forth--both how to program in it, and how it works--and
have never had to teach them anything about how the CPU works.  I don't
even really know how microcode works myself!

Quote:
>Many of the flag and status bits found in a CPU seem to be absent in Forth,
>is this by design or just an oversite?

I don't understand this comment.  I don't know of any other languages
that give you "flag and status bits".  So I'm not sure what it is that's
supposed to be missing from Forth here.

Quote:
>   Some one was wondering about stack manipulation? If you fix an array
>with element zero at the last position item pushed on to the stack, then
>the array elements remain fixed and usable until stack operations cause
>them to be overwritten.  It would be one way to fiddle the elements of
>the stack around with ease and have unlimited access to the stack.

Er, if I understand you correctly, you are asking if it is possible to
use a pointer to the stack?  And treat the stack as a virtual array?  (I
presume this is what you mean by the strange phrase "fix an array".)
The answer is yes, on some systems, but on others you will probably get
a memory protection fault or some such error.  Or, worse yet, on a
segmented memory machine like the 8086, you might end up referencing
some other random section of memory!  And never know it!!  Furthermore,
you don't even know if the stack grows up or down!  It grows down on
most microcomputers, but up on some mainframes.  So any such tricks
would be *highly* machine dependent!!

I think that you're too caught up in the idea of this "virtual machine"
thing.  Forth is a virtual machine in the same sense that LISP is a
virtual machine.  It's not an emulation of some mythical CPU.  It's an
abstraction.  And it remains, first and foremost, a language.
--
Chris Waters    | I think, there- | "Never look a gift horse in the mouth"



Tue, 24 Oct 1995 04:46:00 GMT  
 Forth Core and Kernel Design

Quote:

> Some one was wondering about stack manipulation? If you fix an array with
> element zero at the last position item pushed on to the stack, then the
> array elements remain fixed and usable until stack operations cause them to
> be overwritten.  It would be one way to fiddle the elements of the stack
> around with ease and have unlimited access to the stack.

Yes, but then you need the hardware to address the array, and the instruction
decoding to address them, and probably other complications.  A
non-addressable stack is more limiting, but much simpler.  For many
applications, it is a worthwhile trade-off.

One more point: an addressable stack may make some code simpler, but also
make other code much more difficult to read, to debug, etc.  A few cells of
local variables might be more effective and simpler to deal with than an
addressable stack.  The Novix chips had some fast access memory.  Another
chip might use an addressable stack just for locals.  There are probably lots
of ways to provide a small amount of local variables.

--




Wed, 25 Oct 1995 04:15:36 GMT  
 Forth Core and Kernel Design

        Forth Cores and Kernels Design
        ------------------------------ part 4

   I will digress a bit here to explain my view of a Virtual Machine in
answer to some of the questions directed my way.

   To me the Virtual Machine is a simulation of a CPU.  In Forth this
simulation is the collection of Flags, Registers, and Words that are
found in the Forth programming language.

   Yes a Virtual Machine is a mythical CPU which is being simulated
by/on/with a real CPU.  This virtual machine is one part of Forth.
The other parts are:
1. the Words that make-up the language.
2. the Compiler that builds new words into the dictionary space.
3. the Interpreter a high level user interface to the compiler.
4. the Virtual Machine that executes the Forth Language.
5. the Dictionary Space, a linear section of memory space.
6. the Flags to indicate trouble, divide by zero, overrange, ...
   the number is a negative value, memory or bus-error, ...

   The instructions of the Real CPU are layed down in memory in a linear
fashion. Mnenomic used to define these machine instructions are the set
of assembler instructions used to write programs.  The assembler then
translates the

label:   opcode  source,destinstion    ;comments

into a Real Machine Instruction or binary words stored in memory.  These
machine instructions are made-up of two parts, with the second appearing
twice in some instructions:
1. the instruction
2. the register or pointer or immediate data or absolute address to the
piece of data used during the execution of the instruction.

   If these are layed down in linear memory they may consume more than one
memory location.

   opcode  - usually only one memory location
   xxxxxx  - maybe one or two memory locations or none
   xxxxxx  - maybe one or two memory locations or none
   opcode  - the result be 1 to 5 memory locations used per opcode.

   Why use more than one type of next call?  I think it inefficient to
require each machine instruction to deal with the movement of the IP or
program counter. Though there are only a few different ways to access the
next machine instruction.  Would it not be in the spirit of decomposing
the problem to its smallest elements then to use a seperate next call for
each of the different types of access <absolute, indirect, IP-relative,
indirect with offset,...> as each instruction completes and its time to
move on to the next.

   I should note here that some machine instructions consume the source and
destination that follow as apart of their execution. The 'add' instruction.
These types of opcodes are inline and cause no change in the direction of
the programs algorithmic execution. When the instruction is finished the
CPU moves down <a relative term here> to the next instruction. But the IP
was pointing at the beginning of the opcode and still needs to get over
the extra pieces below.

   Why do I think there needs to be more than one type of Next ?
Because I think there is need for more than one. As has been pointed out
there are machine specific problems _BUT_ we are dealing with a Mythical
Machine a VCPU being simulated upon a Real Machine and the way the Virtual
Machine is designed is machine independent. I do agree that some Real
Machines would have trouble with some things and others are not being used
to their fullest--This is a problem with all Virtual Machines.

   Oh and why not have the _Interrupt_  handling as a part of our Virtual
Machine?  Since it is just our imagination at work we can do anything can't
we?  And the problem of implementation still remains a <real> machine specific
problem, a part of the building of the Virtual Machine, and not a part of
the problem of Forth Core Design, or The Forth Language.

   I am still concerned with the problem of addressing.  Forth seems to
assume the Dictionary is a linear memory space for the Vitual Machine and
ignores the other types of memory access that are used and needed for many
types of programming.

1. indirect memory where the IP relative mode is needed to find the data.
   Although this is basicly what is happening in dictionary access.

2. absolute as in an interrupt or serial port chip, that does not move.

3. indirect where the block of memory is somewhere in memory space but may
   move around.  The offset and index are also useful here, when the block
   is to be sub-divided into several parts. <structures>

4. the use of registers as storage elements.

   In theory the Virtual Machine is a part of the Forth Dictionary or
should be!  In a system with an Operating System the loader will handle
the moving of the Dictionary into memory and start the Virtual Machine.
In a non-OS machine the kernel may contain a loader to clear out memory
to a known value or do other things to get the real-CPU up and running.
But in an machine with a loader what does the kernel do? <Set-up the
virtual machine?>  The problem here is the Virtual Machine is a real
part of Forth but it is ignored?  Why??

   Forth seems to be self-contained in the Dictionary. An ever-expanding
virtual machine <Very elegant>.  There would seem to be no reason for it
not to be able to run as fast as a well written assembler program yet it
does not.?  Perhaps this is due to the simple design of the Virtual Machine?
Is a stripped down CPU really the best choice; I wonder (?) Considering the
effort put into allowing for a extensiable language.?????.

   Some of the arguements I am seeing on this UseNet.News.group would seem
to be a direct result of the problems and concerns I express above.
   I think the Forth Language was designed in a time before the intricite
designs of todays Computers and some of the problems encountered are those
of trying to use an older design pardigm to express newer solutions. Like
on systems that seperate program and data space! Or have hardware stacks!

   To re-explain about stacks.  In most cases the stack is in memory.
An array is a set of pointers to storage, usually of a fixed size.  So the
arguement that the stack is <a real> machine specific problem is also true
for the array, thus I would think that the two will cancel out. With the
result that it can be assumed that an array would be able to point to the
elements of the stack. And the elements of the array count from the top of
the stack down toward the end/first value pushed. The array can be viewed as
a fixed set of pointers to the data being held in the stack.
   In use   array(x)  is a reference to one of the elements of the array.
Or in Forth  x array  would be more correct. The x being the element to use
from the array.
   By fixing an array you lock the stack image into the array pointers, of
course the stack operations may cause this data to be lost. For the stack
and the array are both pointing to the same set of data.
   That is what I was getting at before.

   I think I am catching on to some of this puzzle. Slowly!
   < Am I getting Warmer? >


--



Wed, 25 Oct 1995 13:41:21 GMT  
 Forth Core and Kernel Design

Quote:

>        Forth Cores and Kernels Design
>        ------------------------------ part 4

>   I will digress a bit here to explain my view of a Virtual Machine in
>answer to some of the questions directed my way.

>   To me the Virtual Machine is a simulation of a CPU.  

In a *very* loose sense only!  I think you are taking this analogy *far*
too seriously, and worse, you are looking in vain for CISC CPU design
features in Forth, and expressing surprize and shock when you don't find
them.  This is because Forth does not resemble a CISC CPU, nor is it
intended to.  I suggest that you should *forget* all this stuff you know
about CPU design, and concentrate on learning Forth.  Once you
understand Forth, and why it works the way it does, then come back to
look at the "virtual machine" idea.

Quote:
>   The instructions of the Real CPU are layed down in memory in a linear
>fashion.

Not necessarily.  This is a common approach in CPU design (and a simple
one), but there are many other approaches used, especially in mainframes
and parallel processing machines.

Quote:
>   Why use more than one type of next call?  I think it inefficient to
>require each machine instruction to deal with the movement of the IP or
>program counter.

They're not machine instructions.  They are words in Forth.  And Forth,
if you'll recall is a stack-oriented language.  Most words in Forth take
their data from the stack.  Not from in-line following the "opcode".

The exceptions (words like BRANCH) are few and far between.  And yes, in
many implementations (especially on machines with less powerful machine
language) there will be common exit points for the various branch
words.  On other machines there won't be, because it's more efficient to
code the increment-IP-then-do-the-standard-NEXT-thing inline.  Just as
on many machines, NEXT is coded in-line, rather than as a separate routine.

Quote:
>Though there are only a few different ways to access the
>next machine instruction.  Would it not be in the spirit of decomposing
>the problem to its smallest elements then to use a seperate next call for
>each of the different types of access <absolute, indirect, IP-relative,
>indirect with offset,...> as each instruction completes and its time to
>move on to the next.

NEXT is not necessarily a call--it may be a macro--and 97% of all Forth
words use NEXT rather than anything else.  Addressing is done through
the stack.  This is where your analogy of the "virtual Forth machine" as
"virtual CPU" breaks down.  Forth words only have one "addressing mode".
Stack-relative.

Quote:
>   Why do I think there needs to be more than one type of Next ?
>Because I think there is need for more than one. As has been pointed out
>there are machine specific problems _BUT_ we are dealing with a Mythical
>Machine a VCPU being simulated upon a Real Machine and the way the Virtual
>Machine is designed is machine independent.

Yes, but NEXT is really not part of the "virtual Forth machine".  Some
Forth systems use subroutine threading, rather than a NEXT mechanism.
Some Forth systems actually compile down to machine code, rather than
using any sort of threading.  The "virtual Forth machine" has to do with
dual-stack design, rather than with any particular form of direct,
indirect, or whatever, sort of threading.  NEXT, otoh, has to do
completely with threading.

Quote:
>   Oh and why not have the _Interrupt_  handling as a part of our Virtual
>Machine?  Since it is just our imagination at work we can do anything can't
>we?

Er, just our imagination?  Am I misunderstanding something here?  Forth
is a real language, used in the real world for solving real problems and
writing real code.  It is hardly "just" our imagination.

For that matter NON-virtual Forth machines have been built.  Actual
Forth-in-Silicon chips.  Again, these are most definitely *not*
imaginary.  If you want to understand Forth as a virtual CPU, perhaps
you should study the design of these chips.
--
Chris Waters    | I think, there- | "Never look a gift horse in the mouth"



Wed, 25 Oct 1995 20:04:52 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Forth Core and Kernel Design

2. forth core and kernel

3. FORTH Kernel Design -- Parameter Stack Size?

4. tcltest core dump on linuxppc-R5 kernel 2.2.10

5. Kernel Calls, Best Design

6. Linux Kernel Design and Why Python is Rad

7. kernel forth

8. Fwd(2): 3-stack Forth in the Linux kernel

9. An Almost-Z180 FORTH Kernel

10. Forth kernel for Hitachi H8/300 H series

11. Searching for a basic Forth kernel

12. high level forth kernel?

 

 
Powered by phpBB® Forum Software