yrdbrd@bmcg.UUCP (Larry J. Huntley) (05/25/85)
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?
Ignorantly,
'brd
--
Larry J. Huntley Burroughs -(B)- Corporation
Advanced Systems Group MS-703
10850 Via Frontera San Diego, CA 92128
(619) 485-4544
-*- "Dear Friends, It's 'ORGAN LEROY' at his organ again." -*- wls@astrovax.UUCP (William L. Sebok) (05/31/85)
> 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
wmb@sun.uucp (Mitch Bradley) (06/03/85)
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).