NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/4025

Text File | 1993-01-28 | 8.4 KB | 182 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!ukma!darwin.sura.net!spool.mu.edu!torn!nott!uotcsi2!news
From: [e-mail] (Christopher Browne)
Subject: Is Forth a "Real OS"? (Was re: Documentation)
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: prgv
Organization: Dept. of Computer Science, University of Ottawa
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 28 Jan 93 15:00:17 GMT
Lines: 169

In article <[e-mail]> [e-mail] (Bernd Paysan) writes:
>
>I only want to pick out some lines of your long article:

Likewise...
Minor comment:  Try to keep your line lengths to under 75 characters.
If you don't, it makes followups very difficult to read.

>MH>No, under a normal OS, it's primitives are the right ones, and
>MH>there is no reason to implement BLOCK because:
>MH>
>MH>   1. Many disk ops read/write MUCH less than 1024 bytes.
>MH>   2. OS's provide their own block-style buffering and usually
>MH>      in chunks less than 1024 bytes.
>
>Oups. Both my hard disk and my floppy works in chunks exactly 1 K (2b
>depending on the size of the disk. My MS-DOS PC works with chunks of
>1K for DD, and 512 bytes for HD floppies. The hard disk read in
>chunks of 4K, because it is one partition of 105 MB and it can't be
>less (8 sectors/cluster).

Which means that you can show an particular operating system for which
Mike's assertion is NOT correct.  However, he wasn't saying that it
was a UNIVERSAL fact, but merely that "many disk ops do less than 1K."

>But your second argument is exactly what I say: OS provide
>block-style buffering at their low level disk I/O. The OS has to
>implement block. And if you read chunks with block-size, the OS works
>at best. Reading much less than 1K results
>in incredibly high overhead.

Is there an "incredibly high overhead"?  Precisely WHY is this the
case?

If the OS reads in 1K of data, which may actually be how it does
things at the hardware level, and a particular file only uses 75 bytes
of that 1K, how does the performance differ from the situation where a
BLOCK is used, and the only data referred to is in that 75 byte
section of the block?

There may be "overhead", but it seems to me that it's overhead that
doesn't really cost anything.

>MH>Whatever you bring your Forth or any other Forth up on, however it boots,
>MH>whatever it does, it myopically only supports compiled Forth code.
>
>And the Church's thesis says: Then it supports everything else, too,
>because you can do everything else once you can do it in Forth (or in
>Turing machine). Forth is an universal language, and has good
>performance, too (which Turing's machine hasn't).

Bogus use of theoretical argument:  OF COURSE, since Forth is a Turing
machine equivalent, it can, in theory support any sort of computation.

However, theoretically supported computations are not the issue.  The
issue is, can your bigForth system LOAD and EXECUTE programs that were
written in OTHER languages, and compiled into binary executable form
that your computer's operating system supports.

Can you load TOS/TTP programs from bigForth (which I gather runs on an
Atari ST)?  THAT would be the first step in having language
interoperability.  If, as well, you can pass parameters to the
programs, that's the next step.

>MH>I feel strongly about this because it's one of the reasons Forth is
>MH>so strongly rejected by professionals who KNOW operating systems,
>MH>other languages, real-world uses for computers.  Loud
>MH>claims that Forth is an operating system is dismissed as so
>MH>much hype, and wisely so.
>

>I KNOW about operating systems, other languages and real-world uses
>for computers. And there are many computers that run only FORTH and
>nothing else.  According to your words, they won't work, because they
>have no OS, but only an interactive language running. How does it run,
>without OS?

They can run applications written in Forth, but probably can't do
anything else.  Of course, they're probably embedded systems that may
not have the same kind of I/O capabilities as a "general purpose
computer", and thus have no NEED of any particular OS support.

>If you realy NEED a file system, why didn't everybody
>implement it? And I'll give you a reference: There was an article in
>the "Vierte Dimension", the german Forth magazine, I think in 1/89,
>about "Block World", a unix-style file system implemented by using the
>block interface. The implementation differs much from Unix, but the
>functionality is about the same.

The only people that DIDN'T implement a file system are those that are
"keeping the faith" about BLOCKs.

>To your claim about "tiny basic": As far as I know, tiny basic
>implements all features of ANSI BASIC (which are few enough to call
>it "tiny"). Tiny pascal is about the same: You can't compare it with
>Turbo-Pascal, but it is Pascal. I think, tiny pascal is distributed
>with F-PC or related to F-PC.

If it can't be compared with Turbo Pascal, then what is the point to
it?  If you can't take (say) Turbo Pascal programs and load them
directly in, but rather have to rewrite them, then you might as well
rewrite the whole application in Forth.

What people REALLY want is to not even need to CARE about whether
there's a Pascal compiler, or whether the program was written in
Pascal, or C, or Modula-2.  They want to be able to load the binary
executable file.  On a system that actually DOES have an operating
system, that's fairly straightforward.  Under TOS, the appropriate
system call is pexec().

>MH>In my mind, the Forth community needs to spend more time figuring out how
>MH>to get Forth to LIVE EASILY under real existing operating systems.
>MH>Throw out blocks would be a good start.
>
>Why do you want to throw out blocks? bigFORTH, LMI Forth, JFORTH and
>others live easily under real existing operating systems or
>MS-DOESn't. There is no READLINE in many existing operating systems,
>this is only a C/Forth/Pascal library function. So stream files with
>line ends are no real parts of operating system.

"Not real parts"?  The operating system makes it extremely convenient
to use stream files.  The BASIC LEVEL of operation in a stream is on
the CHARACTER, which is most definitely not a LINE.  We're not talking
about "line-based" systems, but on STREAM FILES.

>Just the other way round: Two years ago, here was a 370 compatible
>mainframe from Siemens, running IBM's CMS/VMSP. This OS uses fixed
>records for storing text files. Waste of space? Doesn't count. The
>earlier versions of OS/370 allocated one cylinder for each file.
>Hundrets of KB wasted. Very efficient for large files like data bases
>or so.

That's ONE example of extreme wastage of disk space.  On a computer
from the "enormous mainframe" family that appears to be waning, due to
the increasing power and efficiency of smaller machines.

>MH>It'll make a difference when you fill that 50MB up.  Then the 50%
>MH>of space wasted in those BLOCKS will seem more important.
>
>The rest of my 50 MB are filled up with text files, binaries and
>stuff like this.

That's an answer?!?

Once your 50 MB is filled, and you find that you have to either
a) Delete files,
b) Find some way of making more efficient use of the 50 MB, or
c) Stop work, because you're out of space,
the wastage on BLOCKS will seem more important.

>MH>This is the kind of attitude that the "progressives" in this
>MH>newsgroup mention often... justification of why the "waste" of BLOCKS
>MH>is not important, or why it's OK for Forth source to be in a format
>MH>that is completely alien to the host OS.  Rationalization run rampant.

>Block files aren't completely alien to the host OS. Only native blocks
>without files are alien. Conversion is stupid simple. If you don't
>like blocks, throw them out in your Forth. I don't want my costomers
>run away, if I do so. I don't want my applications to stop run.

Block files are a relatively alien concept to PROGRAMMERS.  They're a
stumbling block that makes programmers say "Forth?  It can't even
interface with modern computer systems.  Hardly a modern language."

--
Christopher Browne                |     PGP 2.0 key available
[e-mail]           |======================================
University of Ottawa              | Genius may have its limitations, but
Master of System Science Program  | stupidity is not thus handicapped.