NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/forth/3756

Text File | 1993-01-04 | 5.1 KB | 110 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!spool.mu.edu!torn!mcshub!rob
From: [e-mail] (Rob Sciuk)
Subject: Re: Forth for Sparc and other Unix based computers
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: alpha.innovus.com
Organization: Innovus Inc., Hamilton, Ontario, Canada
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Jan 1993 17:11:43 GMT
Lines: 97

In article <[e-mail]> [e-mail] (Mike Coughlin) writes:

[deletion]

>:
>:      There are versions of Forth that are designed to run on any Unix
>:   workstation. They are written in "C" for portability. For a "free" one,
>:   try TILE from the GNU collection of programs. Of course you will have
>:   to spend time instead of money compiling it and getting it to work.
>:
>:It compiles without a glitch on a SPARC, but it fails the second
>:criterion i.e. it isn't a _native_ code FORTH.  If you are wondering
>:why it has to be native, see the message I was responding to (back on
>:the 9th of Dec).
>:
>     Right, its not native code. But the trouble is that the SPARCstation
>is a Unix box. And Unix works with C. So if you want a native code
>anything on a Unix box you'll have trouble with the documentation. The
>documentation tells you how to write C programs, but finding what you
>need for native code from an assembler is not easy. I've looked and
>I don't know where to find it for any of the Unix boxes I have access
>to. For all I know some companies might consider it to be a trade secret.
>I haven't noticed any Forth systems for Unix boxes that were not written
>as C programs.

Most C compilers support the -S option of to generate the ASSEMBLY code
necessary to perform the OS task required.  Write it in C, look at the
assembly, and use that as a model.

BUT:

As you are probably aware, there are several schools of thought
regarding FORTH.  Some regard FORTH as a language, others as an
operating system/language.

When FORTH is `hosted' on an operating system such as Unix, which may
either be a workstation, or a multiuser minicomputer, it is generally
a good idea to use the standard system interface for I/O, scheduling,
interrupts etc. or risk crashing your general purpose OS.  In this
context, FORTH becomes a language only.

On a single user platform, such as MSDOS or Windoze on Intel based
boxes, either approach is viable:

    o  If you want to develop device drivers, interrupt handlers, etc,
    the only one you nuke is yourself, and a <ctrl alt del> (or more likely
    a power off/on) can bring you back to sanity (or at least DOS ;-).

    o  If you want to use MSDOS routines, or files ... you can

    o  If you want to write to the BIOS, or even the hardware directly,
    you can develop the whole OS etc.  and have your Intel box boot
    FORTH (or whatever you call your own particular nightmare) with
    block based file systems etc.

When using big iron, with multiple users, the standard C interface to the
system calls can be ignored, and you can make system calls directly -- if
you know how, and specifically on your target platform, and at your own risk.

Assembly language implementations of FORTH under Unix may give a slight speed
advantage over C based routines, but in (most?) I/O intensive applications,
you will still be constrained by the OS itself.  What you gain in performance
(slight) you lose in portability.

>     Lets hope somebody who knows how to program a SPARKstation or other
>Unix box down to the bare metal will enlighten us all.
>
>--
>   Michael Coughlin             [e-mail]

So what is it that you want?  A SPARC based stand alone FORTH system, or a
general purpose Un*x OS that can run FORTH applications?  If you need real
time FORTH, consider using an Intel platform and one of the commercial native
(non-hosted) variants that are out there.  If THAT isn't fast enough, throw out
your OS, get the hardware reference manual for your RISC platform (if you can),
a cross development environment, an assembler, and start hacking (have fun ;-).

My own C based FORTH is based on the Forth-83 standard, and runs unchanged on
just about every platform that has a K&R C compiler, and that I have intimate
access to (MPE/V, MPE/XL, HP-UX (MC68K and PA-RISC), MSDOS, etc).  FORTH
applications run transparently across each implementation.  AND it's fast
enough (for me).

In addition, I have successfully linked OS libraries
into my FORTH to give interactive development for such things as DBMS's,
GUI's, memory allocation, etc. on a platform specific basis (great for
prototyping without C's compile/link/edit cycle).

I would suggest that all of the features of my roll_your_own are also true with
TILE, and it has the added advantage of a larger installed base.

Assembly bigots take note -- elegance has many forms.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rob Sciuk       [e-mail] OR [e-mail]
Innovus Inc.    204-200 James St S. Hamilton, Ont.      Phone:  [phone]
                {not a flame ... merely a glimmer ...}  Fax:    [phone]