🚀 go-pugleaf

> I am looking for a Forth which will run on a VAX 11/780 under
> System 5.2 or a Forth which will run on a Burroughs XE-550
> (a.k.a. Convergent Technology Mega-Frame.)  I had a copy of
> Kitt Peak Forth running, but that was under 4.1 BSD.
> (Anyone out there of the wizard persuasion - is it feasible to
> run the Kitt Peak version under our new Sys V?)
> Thanks for any and all help.
> 
> P.s.  Where is Bill Sebok when we need him?
> Larry J. Huntley         Burroughs -(B)- Corporation

I'm still here.  I've just been too buried to follow the discussion much
except sporadically.  I have no access to a System 5.2 VAX so I have not
been able to add the #ifdef's to my Forth to run under such a system.  I
don't think it would be all that hard.  If somebody with a System 5.2 VAX
reasonably close to Princeton would give me an account on their machine
I might be tempted to try it.

I intend to post version 3.0 of Princeton Forth for the VAX 4.X BSD sometime
near the end of the summer.  New goodies are being added.  The main one
being added at the moment is dynamic subroutine loading.  This lets you
load subroutines written in some other language into Forth memory and
execute them as Forth words.  I am talking about this (mainly the pitfalls
encountered) at the upcoming Forth conference in Rochester.

Princeton Forth, by the way, is another Forth that compiles directly into
machine language rather than address threaded code (personally I think that is
the only way to go on the VAX).  It has been around since 1982 and is used
here for image processing where speed is the name of the game.  Some of its
characteristics include separate stacks for strings and floating point
quantities.

The main thing that I am happy to report is that I have solved the problem
of allowing the C routine malloc() to coexist with Forth memory layout.
malloc() is called by many C (and Fortran and Pascal) routines and especially
is called by the ubiquitous stdio routines.

I've solved the problem in a way that imposes no new restrictions on either
Forth or the non-Forth subroutine. The modifications are mainly to FORGET with
minor ones to malloc().  Since I have written my own version of malloc() I can
include the suitably modified version of it in my next Forth posting. This
version, of malloc() is, by the way, I think superior to either 4.2 BSD's or the
original 4.1 BSD's and I have intended to post it on its own if I ever got
around to documenting it.

The problem occurs when malloc() is called and then a FORGET is issued.
Suppose pointers to the malloc'ed memory are saved somewhere in the memory of
the calling subroutine.  These pointers are no longer valid after a FORGET.
Attempts to use these pointers will cause an illegal memory access.  The issue
is made hard if one wants to use standard library routines which are unaware of
Forth's use of memory.

The problem has been solved in this way:

A call to free() which frees memory adjacent to the dictionary pointer will
cause the dictionary pointer to be moved back to the beginning of the area
freed.  A call to malloc() which cannot be satisfied from existing free areas
causes the dictionary pointer to be advanced.  If a FORGET is issued and the
memory to be forgotten contains one or more areas allocated by malloc() and not
free()ed then in addition to its usual actions FORGET takes these actions:

1) The dictionary pointer is moved back to the end of the last area allocated
by malloc().

2) The areas of memory that are above the FORGET point but are between the
malloc() allocated memory areas are marked "free" as if they had been freed
by the library free() routine.  Thus this memory will be the first memory
reused by further calls to malloc().

The net effect of all of this is that malloc(), free() and normal dictionary
growth and FORGETing can co-exist in the same memory, without the necessity of
pre-allocation of fixed size areas of memory to either malloc() or to
dictionary growth.
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls

Isn't the Mega-Frame a 680x0 machine?  If so, I have a 68000/68010
Forth system that runs on just about any 68000 Unix system.  It has
been successfully used on a number of such machines; Suns, Dual, Masscomp,
etc.  It is based on the public domain F83 system, but has been converted
to a full 32-bit implementation.  It uses normal Unix files instead of
BLOCKs, and interfaces well to Unix, including the ability to dynamically
load and execute Unix object files (like C subroutines for instance)
under Forth.

The whole distribution, including source code, meta compiler, utilities,
libraries, documentation, runs to about 1.5 MBytes, so it's a little large
to post unless there's lots of interest.  However, it is on the Sun
User Group contributed software tape, so some people may be able to get it
that way.

Another way to get it is to send me a tape and a postage-paid return
envelope.  If you want to go this route, reply to me via e-mail and
I'll tell you the address (unless there are lots of replies, in which
case I may post it to the net).