Lpc2000

>    From: Robert Wood <robert.wood@...>

> I'm honestly not wishing to be rude -*please* don't take offence, but I 
> just don't see anything that gives you any advantage over running an OCD 
> with a JTAG type interface and writing in C.

I've been beaten up so often for using Forth that I'm almost 
impermeable on the topic. Besides, you weren't rude. My response 
is rather long, and I apologise in advance to those I may 
offend, but debugging methodology is a particular hobby-horse of 
mine. 

> This is exactly the sort of stuff the chaps at PAC would
> say and when I asked them why that was good they'd just
> shrug and say because it helps you develop faster! They
> couldn't explain why what you have said below is faster
> than assembler/C with an emulator/OCD. 

At the software debug level, JTAG/emulator/OCD is just the 
interface between the host and the target during debug/test. 
Also important is the user's methodology. What is also important 
is maintenance of the level of abstraction at which you work. 
Debugging is application of scientific method:

while bugs exist:
  while this bug exists:
    observation
    hypothesis
    experiment
    fix

People who can debug well just perform these operations better 
and faster than those who cannot debug well. The core element is 
the innermost loop. Interactive languages such as Forth, 
Smalltalk, Basic and Lisp permit you to write small routines at 
the keyboard and execute them immediately. This promotes the 
hypothesis and experiment sections. Staying within the same 
level of abstraction reduces time. In a good Forth environment, 
you stay at the same level of abstraction all the time.

During debug of hardware I'll regularly type lines such as:

: t begin  $E0000000 @ drop  key? until  ;
t

This defines t to poll an address until a key is pressed. Then 
I'll put a scope probe somewhere. It takes a few seconds, tests 
a hypothesis and gives an experimental result. An interactive 
language with an integral compiler is quicker to use than a 
batch system.

> I understand that Forth is the monitor program

It's not really the monitor program, it's the working 
environment. "Fluffy hand-waving" you may say, but it's the 
difference between approaches that changes how you work.

> but statements like ... just remind me of PAC

We supplied several compilers to them, so it is probably better 
to say nothing.

> Why does this:
> 
> "Forth gives you interactive debugging on the target with *every*
> function ("word" in Forth parlance) visible to you."
> 
> Give you any more than a compiler/debugger/emulator type method?

Because you get round those pesky debugging operations faster in 
many cases.

A secondary advantage comes from the efficient Forth procedure 
call/return mechanism. This is less so with modern frameless C 
compiler techniques, but it promotes writing very short 
routines. These are easier to test, and thorough testing 
enhances software reliability. Well designed short routines are 
reusable, and so code tends to be shorter.

The quote below is relevant.

> From: "rtstofer" <rstofer@...>

> At the time, disk controllers were complex circuit boards with lot of
> parts and drives weren't all that reliable.
> 
> One of the controller manufacturers I visited used Forth extensively
> in their testing process because it allowed for bottom-up testing and
> debugging.
> 
> Write the code to send bits to a port.
> Write code to call the port code and send commands to the port.
> ...etc.  Always building from the bottom up.
> 
> At each step of the development all the lower level code was available. 
> 
> Now, the neat thing was the simplicity of interactively defining a new
> word (function) that would simply extend the underlying, already known
> working, code.  Need a different functional test?  Define a word that
> uses what is already known working and interactively available.
> 
> I was staggered by the simplicity.  I was not converted, just staggered. 

Forth is not a cure for cancer - it's just another programming 
language. In certain application domains it scores very well for 
productivity. Embedded systems is one such domain.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads