FORTH
Bob Flanders
Nick Seidenman
Bob Flanders
Bill Rubenstein
Also, a copy of a Forth implementation for the 6809. I wrote a Forth
which ran on the S/1. Bringing up Forth on a new machine is relatively
easy -- there are some routines which need to be written in assembler
language. But, much of the code can be written in Forth which could be
re-coded in A/L if it was too slow.
I've always been a fan of RPN languages (Forth is one), have always used
HP RPN calculators, and designed an RPN job control language which ran
on over 1000 S/1s for many years in a production environment.
Bill
John R Pierce
> Do any of you know about the language FORTH?
> http://en.wikipedia.org/wiki/Forth_(programming_language)
> file holding the interpreter was labeled FOURTH, for 4th (next)
> generation software—but the IBM 1130
> compile-link-go third-generation programming languages
>
> I contacted Mr. Moore recently to see if he had the source code lying
> around, but unfortunately, it has been lost.
>
the assembler language core of a Forth interpreter is quite small, it
wouldn't be that hard to reproduce. the core interpreter is little
more than a loop of branch double indirect. most of the runtime is
written in forth.
me, I have fond memories of dinking around with a Forth variant called
STOIC circa 1977 or 78, it ran on CP/M and was public domain, and
distributed by the CP/M Users Group. there were some things about Forth
which I found distasteful, like the crude page addressing model of forth
functions. Stoic was the same sort of threaded interpreter, but it had
support for proper file systems (like CP/M)
meanwhile, I remember the 1130 had all kinda cool languages like SNOBOL,
the already mentioned APL, etc etc.
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
Bob Flanders
Ross Patterson
Richard Stofer
trying to write Forth for the 1130, I would probably start with
MinForth as it is written in C.
Back in the mid '70s I spent a lot of time connecting hard drives to
things like Apple IIs and various Intel 808x systems. One of the
drive manufacturers did all of their testing with Forth because it was
easy to add new tests over the existing lower level words. This was a
classic case of bottom-up programming but the result was elegant.
If somebody puts Forth together, I will probably have to resurrect the
80x25 display and PS/2 keyboard devices for my FPGA system. In the
real world, we never used the console because we had just 8K and the
console drivers ate too much memory. My system has 16K (because I am
lazy) so adding these devices would have little impact.
OK, the lazy bit... On the FPGA there is sufficient dual-port SRAM
for 16k words of memory. The CPU is on one side and the DMA arbiter
is on the other. There is NEVER any contention. If I were to use the
off-chip SRAM, I would have to actually implement cycle-stealing or
interleave memory accesses. Either way, it hasn't been worth the
effort.
I have done quite a bit of programming for the HP 48GX calculator
(back around 94-95) and it took a little time to get up to speed. But
after a few hours, it because quite easy. All of my stuff had to do
with celestial navigation; not terribly useful in the age of GPSs.
RIchard
>
> - Show quoted text -
David Cortesi
Bob Flanders
John Doty
> me, I have fond memories of dinking around with a Forth variant called
> STOIC circa 1977 or 78, it ran on CP/M and was public domain, and
> distributed by the CP/M Users Group. there were some things about Forth
> which I found distasteful, like the crude page addressing model of forth
> functions. Stoic was the same sort of threaded interpreter, but it had
> support for proper file systems (like CP/M)
STOIC (STtack Oriented Intepreter/Compiler) was the brainchild of Jon Sachs. He first developed it on Data General hardware. At the time, he was working at MIT at the science operations center for the SAS-3 satellite. I was an astrophysics grad student there.
Jon went on to become uncomfortably rich writing a little program called 1-2-3. Meanwhile, Bob Goeke, an MIT systems engineer, created a stripped-down version for the RCA 1802 processor that he called LSE (Laboratory Software Environment). At the MIT CCD lab (where I spent over 20 years on staff) I got great use out of LSE in instrument control applications. One instrument controlled by LSE acquired the first detailed data on Pluto's atmosphere (http://adsabs.harvard.edu/abs/1989Icar...77..148E). I believe there is still an x-ray optics test setup from that era at NASA's Goddard Space Flight Center controlled by an 1802 running LSE.
A few years ago, I recreated LSE (with some changes) in C. There are two versions:
1. A 64 bit *NIX hosted version.
Stable release: http://noqsi.com/images/lse64-0.3.zip
Development: https://github.com/noqsi/LSE64
2. A 32 bit standalone version for ARM.
Development: https://github.com/noqsi/LSE-ARM
I use the hosted version for lab bench automation, and the standalone version for embedded instrument control.
> meanwhile, I remember the 1130 had all kinda cool languages like SNOBOL,
> the already mentioned APL, etc etc.
APL\1130 was unfortunately too slow to be of much use. It kept the user's "workspace" on disk. The very slow disk seek mechanism severely impacted performance. An APL\1130 user introduced me to APL, but for actual work I used APL\360 or Multics APL.
I never used Forth on the 1130, but when I encountered it on other machines its model of integer arithmetic sure looked familiar ;-)
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com
Bob Flanders
3:28 PM (3 hours ago) |
