16 Feb
2000
16 Feb
'00
8:59 a.m.
No, I don't get the point.
The TINY BASIC with which I worked back in the mid-'70's required more ascii
because it was necessary to build the features normally contained in the
"full-up" version.
If one were to have access to the source code for the interpreter, one could
then migrate various function classes to external libraries which would be
incorporated into the ROM set only if they were needed. If you didn't need
the FP library or the high-precision math library, or the file I/O library,
you'd simply leave it out. However, it's MUCH easier to add enough ROM code
space by using a couple already present sockets, if you do need string
processing or floating point functions, it's MUCH easier to use them within
the framework of BASIC than to roll-yer-own implementation of a public
domain FP package. If you put the ascii basic code in one ROM and put the
interpreter in another, it makes a big difference whether you use TINY basic
rather than a product like MSBasic v5.11.
TINY is OK for some applications, but it doesn't do a lot of the nie things
the "real" basic does. That's why you have to use more code to build the
functions. If you use them often, these little functions can become large
and burdensome. The BASIC source, meaning the stuff you write and feed to
the interpreter, is often MUCH easier to fit into a small system's ROM for a
given task than the equivalent TINY BASIC implementation simply because it's
less verbose than Tiny BASIC code for the same task. YMMV, of course, but
IF you write an interface to an LCD so that PRINT uses it, just being able
enter '?' as a token already saves space. Of course, if you happened to
have a tokenizer for the basic, or, for that matter, TINY BASIC, you'll save
space. Unfortunately, I've never had a tokenized TINY BASIC.
That, basically, (no pun intended) is the reason a REAL source for a REAL
basic interpreter would be interesting. After all, that's one of the
features that's made FORTH as popular as it is.
Dick
-----Original Message-----
From: CLASSICCMP(a)trailing-edge.com <CLASSICCMP(a)trailing-edge.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Wednesday, February 16, 2000 2:32 PM
Subject: Re: Source code for BASIC
install
>Just exactly why would you recommend a TINY BASIC
as opposed to a full-up
>interpreter? Most SBC's support huge amounts of RAM, far in excess of
what
the basic
interpreter should require.
Heck, we can get SBC's of just a few square inches with a Pentium Pro, 128
Mbytes of RAM, SVGA output, and a hard drive interface, why not just Windows NT on the SBC so you can run the latest and
greatest Visual
BASIC++++?
Well, I took your argument there a little too far, but I hope you get the
point: Use the tools appropriate to the job. And for most SBC
applications,
the floating point capabilities and libraries as well
as the file I/O
facilities of a "full-up" BASIC are overkill. OTOH most Tiny Basic
implementations are perfect for the bit-banging and input/output that a
SBC is often called upon to do.
(And yes, I know of other cases where Windows NT and 128 Mbytes of RAM on
the SBC are appropriate, but I don't think any of us want to go down that
road!)
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927