29 Feb
2000
29 Feb
'00
1:41 p.m.
This is almost 20 year old memory cells trying to
activate here, but I
thought Forth was generally implemented by "compilation" into a non-standard
pCode which was then run interpretively by a stack oriented run time engine.
That's one way of doing it, but the most traditional (and still most
popular, at least from what I see) way of doing it is to compile
straight to threaded machine code.
Note that even though threaded code is usually most commonly associated
with Forth and other "non-traditional" languages, the technique
is applicable to old-line languages as well. For example, Fortran IV
compilers on the PDP-11 could optionally compile to threaded machine code,
usually producing smaller object code as a result.
Thus, I would have said it was a stack oriented
language. But I guess it
depends on if you're looking at the language itself or how it is normally
executed?
To me, at least, threaded means "you call a subroutine for everything".
For instance, if you want to add two numbers, you push them onto a
(or the) stack and call the add routine. It's the extreme opositte
of "inline" code, to the point where you can think that you're working
on a "virtual" machine that doesn't have the limitations of your
"real" machine (probably why you've confused Forth with p-Code type
intermediate representations - after all, conceptually they aren't that
different!)
--
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
29 Feb
29 Feb
3:43 p.m.
On Tue, Feb 29, 2000 at 10:41:35PM -0500, CLASSICCMP(a)trailing-edge.com wrote:
That's one way of doing it, but the most
traditional (and still most
popular, at least from what I see) way of doing it is to compile
straight to threaded machine code.
I've never understood this. Evidently most/all of the FIG FORTHs produced
threaded code, but I haven't found a single peep about it in the FIST standards
that say it's an inherent part of the language. I've written FORTHs that did
it both ways, very simple-minded in each case but I think it would be pretty
easy to write a FORTH that at least pruned out most of the superfluous stack
use (stuff that gets pushed and then popped right off) and could produce
semi-decent machine code.
Note that even though threaded code is usually most
commonly associated
with Forth and other "non-traditional" languages, the technique
is applicable to old-line languages as well.
Totally. When I ported Small-C to the IBM 370, I had it produce threaded
code, just because my head started to hurt whenever I thought about how to
automate the allocation of base registers. Yeeccchh...
My PDP-11 emulator has several different interpreters inside it for both
threaded code (for the device bootstraps, and for composing complicated
strings for log files) and tokenized code (for the keyboard script language),
they come in really handy. Funny how this stuff seems to be dying out these
days, but then again, if C is really bad at something, it's considered to
be that something's fault, no big surprise I guess. It's a really great
tool for cases where you're willing to lose a little speed to save a lot of
space.
John Wilson
D Bit
1 Mar
1 Mar
12:42 a.m.
At 12:43 AM 3/1/00 -0500, John Wilson wrote:
Funny how this stuff seems to be dying out these
days, but then again, if C is really bad at something, it's considered to
be that something's fault, no big surprise I guess. It's a really great
tool for cases where you're willing to lose a little speed to save a lot of
space.
I remember at least one interpreted C for DOS on a PC in the mid 80s.
We used it to more quickly compile/debug a project that otherwise
took 10-20 minutes to recompile and relink with Microsoft C. It had
its own IDE, so you wouldn't even need to drop down to a DOS prompt.
I can't remember the name of it, though.
Sadly, as we all know, the size of executables or memory footprints
don't seem to matter much to today's developers. Does it matter that
it takes 30 megs or 70 megs to store Windows on a hard drive?
A lot of "old" techniques are present deep inside new technologies.
Java, for instance.
As for the Byte book, I bought mine in 1983 for $22.95, it's
"Threaded Interpreted Languages" by R.G. Loeliger, ISBN 0-07-038360-X,
Byte Books, 1981.
I was all fired up to give a URL with my Amazon affiliate ID
embedded in it, but it's not found there. I don't see R.G.
on the net, either.
I used this book to attempt to write a TIL for the Commodore 64.
The book gives examples in Z-80 code. My attempt ended when
the 1541 disk drive scrogged my only relevant copy of the
source code. I learned a lesson about the importance of backups.
In hindsight, I certainly haven't forgotten the value and appeal
of TILs. I also think life is too short to force people to write
their own editors, or to drop them in block-structured editors.
TILs belong under the hood of big apps, or on the bare metal
of embedded computers.
- John
1:56 a.m.
John Foust wrote:
I remember at least one interpreted C for DOS on a PC in the mid 80s.
We used it to more quickly compile/debug a project that otherwise
took 10-20 minutes to recompile and relink with Microsoft C. It had
its own IDE, so you wouldn't even need to drop down to a DOS prompt.
I can't remember the name of it, though.
You can still get Interactive C for the 68HC11; it was originally
designed for the MIT Lego robot design competition course, the
famed 6.270. Fun stuff, albeit slow. And limited.
http://lcs.www.media.mit.edu/people/fredm/projects/6270/
--
Carlos Murillo-Sanchez email: cem14(a)cornell.edu
428 Phillips Hall, Electrical Engineering Department
Cornell University, Ithaca, NY 14853
4:10 a.m.
At 10:56 AM 3/1/00 -0500, you wrote:
John Foust wrote:
>
> I remember at least one interpreted C for DOS on a PC in the mid 80s.
> We used it to more quickly compile/debug a project that otherwise
> took 10-20 minutes to recompile and relink with Microsoft C. It had
> its own IDE, so you wouldn't even need to drop down to a DOS prompt.
> I can't remember the name of it, though.
C-Terp was the one that I used. I should still have a copy of it here
somewhere.
Joe
3:57 a.m.
John Wilson <wilson(a)dbit.dbit.com> wrote:
I've never understood this. Evidently most/all of the FIG FORTHs produced
threaded code, but I haven't found a single peep about it in the FIST
standards
that say it's an inherent part of the language. I've written FORTHs that did
it both ways, very simple-minded in each case but I think it would be pretty
easy to write a FORTH that at least pruned out most of the superfluous stack
use (stuff that gets pushed and then popped right off) and could produce
semi-decent machine code.
Hi
I think that most of the FIG Forths were done that way to keep
the implementation across various platforms consistant. It surely
wasn't the fastest.
I've done a call threaded Forth on Analog Devices' ADSP2100.
On a 2181 running at 33MHz it can sort 1000 integers in
6.8 milliseconds and that is code written in high level
Forth. I did a lot of peep-hole optimizing to keep the
top elements of the stack in registers when I could.
It also overlaped many words when compiled. Still, it wasn't
the fastest compiler. Analog Devices 'C' compiler took the
same basic source code and ran the sort a about 4 millisec.
Of course, the Forth code fit into less then 200 words of
code while the 'C' code took over 1K words. They spent a
lot more time and money on their optimizer than I did.
If anyone out there doesn't think sorting 1000 signed integers
in 6.8 millisecs isn't fast, code it up on your PC and
see how fast it is.
Dwight
8829
days inactive
8830
days old
5 comments
6 participants
participants (6)
-
cem14＠cornell.edu -
CLASSICCMP＠trailing-edge.com -
elvey＠hal.com -
jfoust＠threedee.com -
rigdonj＠intellistar.net -
wilson＠dbit.dbit.com