| |
Mark wrote:
> This is something that has been bothering me about pbForth ever since
> you developed it... please do not take this as an attack against you or
> your efforts. I do, in fact, truly believe that you have contributed
> significantly to RCX programming - in the same league as David Baum and
> Markus Noga.
Wow! Great company indeed!
> However...
>
> While I can understand the need for something along the lines of a
> byte-code interpreter being necessary on the RCX - I do not see any
> benefit to using the RCX like a mainframe system, where you hook up to
> it via a dumb terminal, and let the RCX do all the work. Considering
> the RCX's tiny size (not physically, but memory-wise), I see it as much
> more practical to consider the RCX as the "dumb"(er) end of the
> connection. You edit the source code as desired on the PC, compile it
> on a PC, and let the PC detect the errors that can be seen in the source
> code, then upload *ONLY* the object code to the RCX, where a bytecode
> interpreter (which is assumed to always be resident) can execute the
> program.
This would be a good idea, and one day, pbForth will get there. I used
to ship a Tcl based shell with pbForth, but it wasn't working well on all
platforms. Here's why pbForth is the way it is, and forgive the history
lesson....
1. Waaaaay back when a well-equipped mini-computer had 32K of RAM, a couple
of terminals, and a hard disk with 10Mb capacity, programmers would enter
their programs via punched cards, or the terminals. They would submit
their source for compilation, and go for coffee. When they came back, the
compiler would point out a few syntax errors, and the cycle would begin again.
I'm not anxious to return to those days, but the point is that the RCX is
the equivalent of a decent minicomputer 20 years ago.
2. The original Forth was developed on such a minicomputer. For that matter,
so was UNIX. It allowed the programmers of the day much finer grained control
over CPU resources. In those days, you didn't worry too much about porting
from one platform to another, you might worry about making different terminals
work with your system. This was the genesis of the "termcap" file so familiar
in *NIX systems today. The Wyse vs DEC terminal debates were like the Windows
vs Mac vs *NIX debates today.
Once again, not the best of programming times, but Forth and *NIX offered a
quantum leap in the ability of programmers to control their machines.
3. pbForth was developed so that almost any source of serial communications, from
an HP calculator, to a PalmPilot, to a PC, Mac, or *NIX machine could interact
with the RCX in a simple way.
Once the firmware is loaded, all you need is a dumb serial link. Now I agree that
the RCX is not the best place to compile bytecodes, but on the other hand, users
of pbForth do not need to mess with compilers and other cross-platform issues.
You edit the file and submit it (hopefully without errors) to the RCX for
compilation. This might make you think carefully about checking the source
for errors before you ask the RCX to compile it.
Now that the RCX has a way of sending the compiled bytecodes BACK to the host in
a canonical S record form for uploading later, the loop is in fact, complete.
4. The RCX should never be considered the "dumber" end of the system. It has
all of the comuting brains needed for even fairly complex algorithms - we just need
to get better at designing algorithms that work around the other limitations.
I know it seems as if I'm pushing pbForth as a magic bullet sometimes. I have been
getting emails from all over the world asking me for more materials, suggestions for
improvements, and even contributions of code. It's not for everyone, though.
I welcome discussions like this because it gets me to take a step back and think
about where pbForth is going. Thanks for prompting me. I'll probably add this
as well as some more history to my website soon.
> This is, basically, how NQC operates... but my biggest beef with it is
> its reliance on the standard Mindstorms firmware, whose limitations (the
> standard firmware, not NQC in particular) make it frustrating, at the
> very least, by people accustomed to real-world software development.
One thing I did was use as much of the ROM as possible. I hook into the
routines so painstakingly mapped out by Kekoa in his internals document.
After all, if the code works for LEGO, why not use it again?
Cheers,
Ralph Hempel - P.Eng
--------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbFORTH>
--------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------
|
|
Message has 1 Reply:
 | | Re: Thought on pbForth
|
| (...) Neither am I... but the fact is that it's not 20 years ago. My attitude is why use computers as if we are? (btw, I was programming back then... and I must confess that there are a few things I miss about programming in that era [most notably, (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | Thought on pbForth
|
| Ralph, This is something that has been bothering me about pbForth ever since you developed it... please do not take this as an attack against you or your efforts. I do, in fact, truly believe that you have contributed significantly to RCX (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.pbforth)
|
7 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
