| |
> Ralph Hempel wrote:
> > I'm still trying to get unifying information for all platforms on my website
> > which would help the confusion a lot.
And Mark Tarrabain wrote:
> Forgive me for flogging a (probably) dead horse, but I still fail to see
> what the problem here is. There is a freely available ANSI C compiler
> for most major systems today, including Mac, Windows, and most Unices.
> Further, I know from a great deal of personal experience that writing
> strict ANSI compliant C code is not nearly as difficult as some people
> have claimed that it is... especially for something like
> compiler-writing.
The basic problem, Mark, is time. I just don't have the time to properly
support a compiler for three platforms. I can barely keep up with the
demands pbForth makes of my spare time.
I write strict ANSI-C all day long, and pbForth is a bit of mental gymnastics
for me.
> > I may even resurrect my Tcl script
> > to do uploading since it works (I think) on Mac/Linux/Win boxes.
>
> Just my 2 cents here, Ralph... but I'm not a big proponent of IDE's in
> general... a command line based system would be plenty adequate, IMO.
> That way, the compiler itself (which could be theoretically 100%
> portable across all platforms) would be easily isolated from a (usually)
> platform-dependant GUI. Develop the IDE for those that want it, but why
> postpone the release of a compiler because of it? NQC seems to have
> done quite well being command line based, after all (with
> platform-dependant front ends, like rcxcc).
Me either. In fact, I really don't like GUIs at all - being a Unix guy from
back when AT&T was giving it away to universities.... The neat thing about
Tcl/Tk is that the Tcl stuff IS command line, and the Tk GUI is just a wrapper
around the Tcl stuff that happens to be platform independent.
Now, as the risk of flogging the horse even more, here is why things are
the way they are...
1. pbForth (or any Forth) was originally desinged to pull the most
functionality possible out of the TARGET machine.
2. Forths are traditionally small, compact, and place few requirements
on the target except maybe a serial port. This makes Forth easy to port.
3. A basic part of Forth is that it is extensible. In fact, the target
is capable of reading source, compiling it into bytecodes, and then
executing it. This is what makes it easy (line ends aside) for the RCX
to compile text from just about any source of plain ASCII characters.
4. If I was to support a bytecode compiler, it would have to essentially
perform the same function that the RCX does now, which is compiling source
into bytecodes. In other words, I would have to write a Forth for each host
machine in C (or Tcl) and then make sure the output was generated in nice
S record format for downloading.
The only advantage I can see to point 4 (correct me if I am wrong here) is
that the compiling might be FASTER. I still need to support the interactive
mode of operation that lets you examine variables and exectute routines
directly from a dumb terminal.
I hope this clears up any confusion about why pbForth is what it is.
Cheers,
Ralph Hempel - P.Eng
------------------------------------------------------
The train stops at the train station,
The bus stops at the bus station,
So why am I sitting at a work station?
------------------------------------------------------
Reply to: rhempel at bmts dot com
------------------------------------------------------
|
|
Message is in Reply To:
 | | Re: TpForth Project ?
|
| (...) Forgive me for flogging a (probably) dead horse, but I still fail to see what the problem here is. There is a freely available ANSI C compiler for most major systems today, including Mac, Windows, and most Unices. Further, I know from a great (...) (25 years ago, 13-Jan-00, to lugnet.robotics.rcx.pbforth)
|
6 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
